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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZiDmC1uF0S73SI9f@smile.fi.intel.com>
Date: Thu, 18 Apr 2024 12:21:15 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Bartosz Golaszewski <brgl@...ev.pl>
Cc: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Arnd Bergmann <arnd@...db.de>, linux-gpio@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [rfc, PATCH v1 1/1] gpiolib: Get rid of never false
 gpio_is_valid() calls

On Wed, Apr 17, 2024 at 10:47:23PM +0200, Bartosz Golaszewski wrote:
> On Wed, Apr 17, 2024 at 12:46 PM Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> wrote:
> > On Tue, Feb 27, 2024 at 02:06:05PM +0100, Bartosz Golaszewski wrote:
> > > On Wed, Feb 21, 2024 at 10:32 PM Andy Shevchenko
> > > <andriy.shevchenko@...ux.intel.com> wrote:
> > > >
> > > > In the cases when gpio_is_valid() is called with unsigned parameter
> > > > the result is always true in the GPIO library code, hence the check
> > > > for false won't ever be true. Get rid of such calls.
> > > >
> > > > While at it, move GPIO device base to be unsigned to clearly show
> > > > it won't ever be negative. This requires a new definition for the
> > > > maximum GPIO number in the system.
> >
> > > > ---
> > >
> > > It looks like a risky change that late in the release cycle. I want to
> > > avoid some CI problems at rc6. Please resend it once v6.9-rc1 is
> > > tagged.
> >
> > Not sure why resend, but I missed that somehow. Can you consider applying it?
> 
> Applied, thanks!

Thank you!

I have grepped the kernel sources for these use cases:

  $ git grep -n -C6 '= devm_gpio_request([^A-Z]'
  $ git grep -n -C6 '= gpio_request([^A-Z]'

to see how many users might not have checked the validness of the GPIO before
passing to gpio_request(). All what I found is something like ~10 drivers.

They are basically in the risk category of my change.

Another risky part that touches everybody is the base finding algo.
I spent quite a time before sending this patch and looked at it again
to see if there is any potential flaw, but found nothing. Hopefully
we will see no reports or many and sooner than later while it sits
in Linux Next.

TL;DR: the above is a note to be in archives just in case.

-- 
With Best Regards,
Andy Shevchenko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ