Re: [PATCH v5] driver core: enforce device_lock for driver_match_device()

[Greg KH]

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@xxxxxxxxx> wrote:
> >
> > On Wed, Jan 21, 2026 at 9:11 AM Danilo Krummrich <dakr@xxxxxxxxxx> 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