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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALbr=LYUm-T0LphtvSEHxNK=UCQDSEJxeKRn0U+GCsb4SVvu-Q@mail.gmail.com>
Date: Fri, 16 Jan 2026 19:38:33 +0800
From: Gui-Dong Han <hanguidong02@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Danilo Krummrich <dakr@...nel.org>, rafael@...nel.org, linux-kernel@...r.kernel.org, 
	baijiaju1990@...il.com, Qiu-ji Chen <chenqiuji666@...il.com>
Subject: Re: [PATCH v5] driver core: enforce device_lock for driver_match_device()

On Fri, Jan 16, 2026 at 7:19 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Fri, Jan 16, 2026 at 03:34:53PM +0800, Gui-Dong Han wrote:
> > On Wed, Jan 14, 2026 at 3:23 AM Danilo Krummrich <dakr@...nel.org> wrote:
> > >
> > > On Tue Jan 13, 2026 at 5:28 PM CET, Gui-Dong Han wrote:
> > > > Currently, driver_match_device() is called from three sites. One site
> > > > (__device_attach_driver) holds device_lock(dev), but the other two
> > > > (bind_store and __driver_attach) do not. This inconsistency means that
> > > > bus match() callbacks are not guaranteed to be called with the lock
> > > > held.
> > > >
> > > > Fix this by introducing driver_match_device_locked(), which guarantees
> > > > holding the device lock using a scoped guard. Replace the unlocked calls
> > > > in bind_store() and __driver_attach() with this new helper. Also add a
> > > > lock assertion to driver_match_device() to enforce this guarantee.
> > > >
> > > > This consistency also fixes a known race condition. The driver_override
> > > > implementation relies on the device_lock, so the missing lock led to the
> > > > use-after-free (UAF) reported in Bugzilla for buses using this field.
> > > >
> > > > Stress testing the two newly locked paths for 24 hours with
> > > > CONFIG_PROVE_LOCKING and CONFIG_LOCKDEP enabled showed no UAF recurrence
> > > > and no lockdep warnings.
> > > >
> > > > Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
> > >
> > > Fixes: 49b420a13ff9 ("driver core: check bus->match without holding device lock")
> >
> > Thanks for the review! The Fixes tag looks correct as the
> > inconsistency dates back to that commit.
> >
> > Since a Fixes tag is present, I recall the patch bot often warns when
> > a Fixes tag is provided without a corresponding Cc:
> > stable@...r.kernel.org tag. Perhaps we should include it? This would
> > also allow us to fix the UAF in older kernels.
>
> Can you reproduce this UAF?  If so, yes, otherwise fixing for
> theoretical things isn't good to backport.

Yes, it is reproducible. The Bugzilla entry linked in the Closes tag
contains full KASAN reports and PoCs that reliably reproduce the UAF.
(This was also noted in the v1 changelog).

Thanks for the review!