linux-kernel - Re: [PATCH] gpio: omap: do not register driver in probe()

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] [day] [month] [year] [list]

Message-Id: <DFW34RKI0FBC.WRKWPAS6IBN7@kernel.org>
Date: Fri, 23 Jan 2026 16:48:01 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Greg KH" <gregkh@...uxfoundation.org>
Cc: <rafael@...nel.org>, <broonie@...nel.org>, <will@...nel.org>,
 <grygorii.strashko@...com>, <ssantosh@...nel.org>, <khilman@...nel.org>,
 <linusw@...nel.org>, <brgl@...nel.org>, <driver-core@...ts.linux.dev>,
 <linux-kernel@...r.kernel.org>, <linux-omap@...r.kernel.org>,
 <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH] gpio: omap: do not register driver in probe()

On Fri Jan 23, 2026 at 4:23 PM CET, Greg KH wrote:
> On Fri, Jan 23, 2026 at 03:25:43PM +0100, Danilo Krummrich wrote:
>> On Fri Jan 23, 2026 at 3:19 PM CET, Greg KH wrote:
>> > But there are no platform resources for this at all, shouldn't this be a
>> > faux device instead?
>> 
>> Probably, but that's for another patch, since this one may potentially be
>> backported beyond the existence of the faux bus.
>> 
>> > That being said, ignoring the return value of platform_device_register()
>> > is probably not something we want to keep around.
>> 
>> Yes, as mentioned below the commit message, there are a couple of things that
>> need to be followed up on here.
>> 
>> With this patch I only intend to fix the deadlock condition and otherwise keep
>> all the existing semantics as it is.
>> 
>> I.e. maybe it is intentional and this driver should not abort probing if this
>> can't be registered for some reason.
>
> Ok, fair enough, fixing this immediate bug is good enough for me.
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

Just for the record, the things that should still be addressed:

  (1) Potential UAF on module unload: The device is declared as global static
      (should use a dynamic allocation instead); device is never unregistered.

  (2) Handle return value of *_device_register().

  (3) Use faux bus; maybe not directly suitable as omap_mpuio_driver only uses
      struct dev_pm_ops callbacks. Though, we could extend struct
      faux_device_ops accordingly.

- Danilo