linux-kernel - Re: [PATCH v5] driver core: enforce device_lock for driver_match

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

Message-ID: <2026012133-deploy-chief-3a7f@gregkh>
Date: Wed, 21 Jan 2026 08:56:26 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Gui-Dong Han <hanguidong02@...il.com>
Cc: Danilo Krummrich <dakr@...nel.org>, Mark Brown <broonie@...nel.org>,
	rafael@...nel.org, linux-kernel@...r.kernel.org,
	baijiaju1990@...il.com, Qiu-ji Chen <chenqiuji666@...il.com>,
	Aishwarya.TCV@....com, Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [PATCH v5] driver core: enforce device_lock for
 driver_match_device()

On Wed, Jan 21, 2026 at 03:41:56PM +0800, Gui-Dong Han wrote:
> On Wed, Jan 21, 2026 at 3:18 PM Gui-Dong Han <hanguidong02@...il.com> wrote:
> >
> > On Wed, Jan 21, 2026 at 9:11 AM Danilo Krummrich <dakr@...nel.org> wrote:
> > >
> > > On Tue Jan 20, 2026 at 10:18 PM CET, Danilo Krummrich wrote:
> > > > Anyways, this should work:
> > >
> > > I Just notied that I pasted the wrong diff, which was nonsense of course, since
> > > it just unlocks all the suppressed false positives. (Should not have sent it
> > > during a meeting. :)
> > >
> > > What I actually intended (not neat, but hopefully helps):
> >
> > Thanks for the updated diff.
> >
> > I tested it on my QEMU setup. Since I couldn't reproduce the hang
> > there, I didn't see any lockdep splats regarding the deadlock.
> > However, since the physical lock is removed, my PoCs successfully
> > triggered the UAF on both paths as expected.
> >
> > I did notice a lockdep warning during boot, which happens every time.
> > I suspect this is because faux_bus_init is an __init function, so we
> > are registering a key from memory that gets freed. This seems specific
> > to the debug code, but I'm pasting it below for reference.
> 
> I figured out the root cause.
> 
> The warning is triggered because faux_bus_root is a static object.
> lockdep_register_key() has a WARN_ON_ONCE(static_obj(key)) check that
> forbids registering keys residing in static memory. It is not about
> __init memory being freed.
> 
> Anyway, this is not a big deal and doesn't impact the testing results.

Ooh, nice catch.  Let me go make that a dynamic object.  It really
shouldn't be a static one, I hate static struct device usage, and
complain about it from everyone else.  So there's no reason I should
have used that myself :(

thanks,

greg k-h