From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: Johan Hovold <johan@kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
Danilo Krummrich <dakr@kernel.org>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 5.15.y] driver core: fix parent lock use-after-free on USB disconnect
Date: Tue, 3 Nov 2026 09:59:11 -0500 [thread overview]
Message-ID: <20261103145825.4109901-1-sashal@kernel.org> (raw)
In-Reply-To: <2026110359-reps-winking-6c18@gregkh>
From: Johan Hovold <johan@kernel.org>
[ Upstream commit 0f554506a3fc6a21e714adf38cc3eb0ffe1bb452 ]
USB interfaces should be probed with their parent USB device lock held
and the USB bus therefore sets the need_parent_lock bus flag so that
driver core takes the parent lock when needed.
Driver core is only guaranteed to hold a reference to the parent device
during initial probe however and nothing prevents the device and its
parent from being deregistered and the parent potentially freed, for
example, while iterating over devices in driver_attach() or
bus_rescan_devices_helper().
Since commit 524134d42231 ("USB: don't cancel queued resets when
unbinding drivers") USB interfaces hold a reference to their parent USB
device, but a parent hub may still go away while probing a USB device
(e.g. via the drivers_probe sysfs interface). This can lead to a
use-after-free when taking the parent device lock before checking the
device->p->dead flag of the device being probed.
As only USB interfaces actually need the parent lock, make the
need_parent_lock feature even more fine grained by making it a device
type rather than bus feature. By requiring that any users also make sure
that their devices hold a reference to their parents (like USB does),
driver core can lock a device and its parent without first checking if
the device has been deregistered.
Note that this will also increase parallelism when using asynchronous
probe as USB devices connected to the same hub can now be probed in
parallel.
Fixes: bf74ad5bc417 ("[PATCH] Hold the device's parent's lock during probe and remove")
Cc: stable@vger.kernel.org # 2.6.16: 524134d42231: USB: don't cancel queued resets when unbinding drivers
Cc: stable@vger.kernel.org # 2.6.16
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20261014133109.1392265-2-johan@kernel.org
[ Fix mention of bus vs. device type in __device_driver_{un}lock().
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
[ sashal: adjusted context for non-const USB type declarations and the older bus_type layout ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/base/bus.c | 4 ++--
drivers/base/dd.c | 8 ++++----
drivers/usb/core/driver.c | 1 -
drivers/usb/core/message.c | 1 +
include/linux/device.h | 5 +++++
include/linux/device/bus.h | 3 ---
6 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 3ec131d877120..2720b76adb70e 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -689,10 +689,10 @@ static int __must_check bus_rescan_devices_helper(struct device *dev,
int ret = 0;
if (!dev->driver) {
- if (dev->parent && dev->bus->need_parent_lock)
+ if (dev->type && dev->type->need_parent_lock)
device_lock(dev->parent);
ret = device_attach(dev);
- if (dev->parent && dev->bus->need_parent_lock)
+ if (dev->type && dev->type->need_parent_lock)
device_unlock(dev->parent);
}
return ret < 0 ? ret : 0;
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index daa5ef3f38e92..2db800fcd3d1a 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -1051,7 +1051,7 @@ void device_initial_probe(struct device *dev)
/*
* __device_driver_lock - acquire locks needed to manipulate dev->drv
* @dev: Device we will update driver info for
- * @parent: Parent device. Needed if the bus requires parent lock
+ * @parent: Parent device. Needed if the device type requires parent lock
*
* This function will take the required locks for manipulating dev->drv.
* Normally this will just be the @dev lock, but when called for a USB
@@ -1059,7 +1059,7 @@ void device_initial_probe(struct device *dev)
*/
static void __device_driver_lock(struct device *dev, struct device *parent)
{
- if (parent && dev->bus->need_parent_lock)
+ if (dev->type && dev->type->need_parent_lock && parent)
device_lock(parent);
device_lock(dev);
}
@@ -1067,7 +1067,7 @@ static void __device_driver_lock(struct device *dev, struct device *parent)
/*
* __device_driver_unlock - release locks needed to manipulate dev->drv
* @dev: Device we will update driver info for
- * @parent: Parent device. Needed if the bus requires parent lock
+ * @parent: Parent device. Needed if the device type requires parent lock
*
* This function will release the required locks for manipulating dev->drv.
* Normally this will just be the the @dev lock, but when called for a
@@ -1076,7 +1076,7 @@ static void __device_driver_lock(struct device *dev, struct device *parent)
static void __device_driver_unlock(struct device *dev, struct device *parent)
{
device_unlock(dev);
- if (parent && dev->bus->need_parent_lock)
+ if (dev->type && dev->type->need_parent_lock && parent)
device_unlock(parent);
}
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 072968c40adea..0e7070814c26a 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -2027,5 +2027,4 @@ struct bus_type usb_bus_type = {
.name = "usb",
.match = usb_device_match,
.uevent = usb_uevent,
- .need_parent_lock = true,
};
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 58046946411f1..037f90089eda4 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1915,6 +1915,7 @@ struct device_type usb_if_device_type = {
.name = "usb_interface",
.release = usb_release_interface,
.uevent = usb_if_uevent,
+ .need_parent_lock = true,
};
static struct usb_interface_assoc_descriptor *find_iad(struct usb_device *dev,
diff --git a/include/linux/device.h b/include/linux/device.h
index 8da560db91633..1e0fe91603962 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -84,6 +84,10 @@ int subsys_virtual_register(struct bus_type *subsys,
* information, equivalent to the kobj_type of a kobject.
* If "name" is specified, the uevent will contain it in
* the DEVTYPE variable.
+ *
+ * @need_parent_lock: When probing or removing a device of this type,
+ * driver core should lock the device's parent. Note that
+ * the device must hold a reference to its parent.
*/
struct device_type {
const char *name;
@@ -94,6 +98,7 @@ struct device_type {
void (*release)(struct device *dev);
const struct dev_pm_ops *pm;
+ bool need_parent_lock;
};
/* interface for exporting device attributes */
diff --git a/include/linux/device/bus.h b/include/linux/device/bus.h
index 062777a45a74d..0f805d2a3f018 100644
--- a/include/linux/device/bus.h
+++ b/include/linux/device/bus.h
@@ -67,8 +67,6 @@ struct fwnode_handle;
* @p: The private data of the driver core, only the driver core can
* touch this.
* @lock_key: Lock class key for use by the lock validator
- * @need_parent_lock: When probing or removing a device on this bus, the
- * device core should lock the device's parent.
*
* A bus is a channel between the processor and one or more devices. For the
* purposes of the device model, all devices are connected via a bus, even if
@@ -111,7 +109,6 @@ struct bus_type {
struct subsys_private *p;
struct lock_class_key lock_key;
- bool need_parent_lock;
};
extern int __must_check bus_register(struct bus_type *bus);
--
2.53.0
prev parent reply other threads:[~2026-11-03 14:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 10:12 FAILED: patch "[PATCH] driver core: fix parent lock use-after-free on USB disconnect" failed to apply to 5.15-stable tree gregkh
2026-11-03 14:59 ` Sasha Levin [this message]
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=20261103145825.4109901-1-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=dakr@kernel.org \
--cc=johan@kernel.org \
--cc=stable@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox