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:	Wed, 22 Apr 2009 18:06:11 -0300
From:	Thadeu Lima de Souza Cascardo <cascardo@...oscopio.com>
To:	Greg KH <greg@...ah.com>
Cc:	linux-kernel@...r.kernel.org, gregkh@...e.de,
	linux-input@...r.kernel.org, kay.sievers@...y.org
Subject: Re: [PATCH 0/4] fix some improper uses of dev_set_name

On Tue, Apr 21, 2009 at 10:45:31PM -0700, Greg KH wrote:
> On Mon, Apr 20, 2009 at 09:17:12PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > dev_set_name expects a format string. Many of its uses, however, blindly
> > call it with a string variable that comes from some external, perhaps
> > unreliable source. Some of those uses are safe, like those in the third
> > patch in the series and most of those not fixed by any of them. Some few
> > remaining uses may require some more attention to decide if a patch is
> > really required. Perhaps converting all of them for safeness is a good
> > compromise.
> > 
> > Thadeu Lima de Souza Cascardo (4):
> >   driver core: use string format when name is another device's name
> >   driver core: use string format when name is given to an exported
> >     function
> 
> These two patches were a bit more than just the "driver core".  Care to
> split them up into the subsystem-proper sections and send them to the
> different subsystem maintainers?
> 
> I don't see anything here that can come from a user supplied string, do
> you?  So it's a pretty low priority.
> 
> thanks,
> 
> greg k-h

OK. I will do the split by subsystem and send each one separately to the
maintainer and lkml.

Besides the fourth patch, I think. I will do some more check and,
perhaps, even send it to stable.

The third one will be sent to input subsystem and it is pretty much
2.6.31 material.

For the other two, I've separated them (and joined them) because the
situation is pretty much the same as well as the decision about applying
them into stable, rc, next or not at all.

The first one is when you set a device name using another device's name,
like this:

	dev_set_name(&idkp->dev, dev_name(&drive->gendev));

I've never seen a device name with a '%', but there's currently nothing
stopping any driver of doing that. Perhaps, it is a case-by-case thing,
as gendev may never be named like that. But we may as well decide that
no device may be named like that ever and document this properly or put
the code there that will prohibit that. Then, this patch is useless.

The second one is the case when the function is exported and an
out-of-tree driver may use it giving a name that contains a '%'. If we
don't care about out-of-tree drivers, I may even check every in-tree
user and fix the user instead of/besides the callee. If we DO care about
out-of-tree drivers TOO much, this may even be stable material.

Since I am not sure what the position/decision is about each one, I
would like some input while I work into splitting them into subsystems.

Regards,
Cascardo.

After this message, I think linux-input and Kay may be left out of the
loop.

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ