From: sashiko-bot@kernel.org
To: "Johan Hovold" <johan@kernel.org>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH v2 2/3] driver core: take parent lock on deferred probe
Date: Wed, 14 Oct 2026 13:48:12 +0000 [thread overview]
Message-ID: <sashiko-outbox-171381@kernel.org> (raw)
In-Reply-To: <20261014133109.1392265-3-johan@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] driver core: UAF on dev->parent in bus_probe_device_deferred()
--
commit 768aedc18e0fe23bb1bfe38cd117e5b5a7a2fa43
Author: Johan Hovold <johan@kernel.org>
driver core: take parent lock on deferred probe
This commit adds a new bus_probe_device_deferred() helper to handle
deferred probing while ensuring the parent device lock is taken when
required. This ensures USB interfaces are probed correctly with the
parent lock held.
Link: https://lore.kernel.org/20261007131514.1260696-1-mario.peter@leica-geosystems.com
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index d6668fb8ddea5..43d131fd8085d 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
[ ... ]
> @@ -627,6 +621,26 @@ void bus_probe_device(struct device *dev)
[ ... ]
> +void bus_probe_device_deferred(struct device *dev)
> +{
> + if (dev->type && dev->type->need_parent_lock)
> + device_lock(dev->parent);
[Severity: High]
Can this dereference a freed parent pointer?
In drivers/base/dd.c:deferred_probe_work_func(), the code dequeues
the device and keeps it alive with get_device(), but drops the
deferred_probe_mutex.
If a concurrent device teardown (like a parent device unplug) calls
device_del(dev) while the mutex is dropped, device_del() completes
and drops the parent device reference. If that was the last reference,
the parent is freed. Pinning the child via get_device(dev) does not
keep the parent alive after device_del() has completed.
When the worker thread resumes, it calls bus_probe_device_deferred(dev),
which executes device_lock(dev->parent) here before checking dev->p->dead.
Could this lead to a Use-After-Free regression?
Note that the follow-up patch 3/3 does not fix this regression, but
actually propagates the same pattern to __device_attach_async_helper()
via the newly introduced __device_driver_lock(dev, dev->parent).
> + __bus_probe_device(dev);
> + if (dev->type && dev->type->need_parent_lock)
> + device_unlock(dev->parent);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261014133109.1392265-1-johan@kernel.org?part=2
next prev parent reply other threads:[~2026-10-14 13:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 13:31 [PATCH v2 0/3] driver core: parent lock fixes Johan Hovold
2026-10-14 13:31 ` [PATCH v2 1/3] driver core: fix parent lock use-after-free on USB disconnect Johan Hovold
2026-10-14 13:43 ` sashiko-bot
2026-10-14 14:49 ` Danilo Krummrich
2026-10-14 14:58 ` Alan Stern
2026-10-14 13:31 ` [PATCH v2 2/3] driver core: take parent lock on deferred probe Johan Hovold
2026-10-14 13:48 ` sashiko-bot [this message]
2026-10-14 13:31 ` [PATCH v2 3/3] driver core: take parent lock in async device attach Johan Hovold
2026-10-14 13:40 ` sashiko-bot
2026-10-14 14:52 ` Alan Stern
2026-10-14 14:58 ` Johan Hovold
2026-10-14 23:11 ` [PATCH v2 0/3] driver core: parent lock fixes Danilo Krummrich
2026-10-14 23:12 ` Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-171381@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=johan@kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.