lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 05 Sep 2014 14:32:41 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	David.Laight@...LAB.COM
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH V2 net] core: Don't attempt to load the "" driver.

From: David Laight <David.Laight@...LAB.COM>
Date: Wed, 3 Sep 2014 08:55:21 +0000

> Requests like 'ifconfig ""' cause dev_load(net, "") be called, since
> request_module("") return 0 (success) this generates the error message:
> "Loading kernel module for a network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias netdev- instead."
> 
> Since dev_load() doesn't have to work, just ignore such names.
> 
> Signed-off-by: David Laight <david.laight@...lab.com>
> ---
> 
> V2: Added sign off.
> 
> If you search for the above error message, you'll find a lot of complaints.
> While the applications shouldn't be calling an SIOCxxx ioctl with ifr_name[0] == 0
> the kernel shouldn't be tracing the error either.
> 
> Due to the complaints from users, this might be a backport candidate.

I have to say that I don't like this.

Why is request_module("") signalled with success unconditionally?
A module didn't get loaded, so semantically this behavior makes
no sense at all.

I would rather than simply request_module() signal an error in this
case, and then _NOBODY_ has to have all of this duplicated logic to
check for name[0]=='\0' throughout all of the call chains leading to
request_module().
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ