[PATCH] usb: core: hcd: fix possible deadlock in rh control transfers

[PATCH] usb: core: hcd: fix possible deadlock in rh control transfers

[Oliver Neukum]

From within the SCSI error handler memory allocations must not
trigger IO. Handling errors in UAS and the storage driver may
involve resetting a device. The thread doing the reset itself
relies on VM magic. However, that is insufficient, as resetting
a device involves resuming it. Resumption as well as resetting
involves conrol transfers to the parent of the device to be reset.
That may be a root hub. Hence usbcore must heed the flags passed
to usb_submit_urb() processing control transfers to root hubs.

The problem exist since the storage driver has been merged.

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/usb/core/hcd.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 89221f1ce769..29c74ed40526 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -448,7 +448,8 @@ rh_string(int id, struct usb_hcd const *hcd, u8 *data, unsigned len)
 
 
 /* Root hub control transfers execute synchronously */
-static int rh_call_control (struct usb_hcd *hcd, struct urb *urb)
+static int rh_call_control(struct usb_hcd *hcd,
+		struct urb *urb, gfp_t mem_flags)
 {
 	struct usb_ctrlrequest *cmd;
 	u16		typeReq, wValue, wIndex, wLength;
@@ -483,8 +484,8 @@ static int rh_call_control (struct usb_hcd *hcd, struct urb *urb)
 	 * tbuf should be at least as big as the
 	 * USB hub descriptor.
 	 */
-	tbuf_size =  max_t(u16, sizeof(struct usb_hub_descriptor), wLength);
-	tbuf = kzalloc(tbuf_size, GFP_KERNEL);
+	tbuf_size = max_t(u16, sizeof(struct usb_hub_descriptor), wLength);
+	tbuf = kzalloc(tbuf_size, mem_flags);
 	if (!tbuf) {
 		status = -ENOMEM;
 		goto err_alloc;
@@ -809,12 +810,13 @@ static int rh_queue_status (struct usb_hcd *hcd, struct urb *urb)
 	return retval;
 }
 
-static int rh_urb_enqueue (struct usb_hcd *hcd, struct urb *urb)
+static int rh_urb_enqueue(struct usb_hcd *hcd,
+		struct urb *urb, gfp_t mem_flags)
 {
 	if (usb_endpoint_xfer_int(&urb->ep->desc))
 		return rh_queue_status (hcd, urb);
 	if (usb_endpoint_xfer_control(&urb->ep->desc))
-		return rh_call_control (hcd, urb);
+		return rh_call_control(hcd, urb, mem_flags);
 	return -EINVAL;
 }
 
@@ -1535,7 +1537,7 @@ int usb_hcd_submit_urb (struct urb *urb, gfp_t mem_flags)
 	 */
 
 	if (is_root_hub(urb->dev)) {
-		status = rh_urb_enqueue(hcd, urb);
+		status = rh_urb_enqueue(hcd, urb, mem_flags);
 	} else {
 		status = map_urb_for_dma(hcd, urb, mem_flags);
 		if (likely(status == 0)) {
-- 
2.54.0

[syzbot] [usb?] memory leak in hub_event (4)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    dd6c438c3e64 Merge tag 'vfs-7.1-rc1.fixes' of git://git.ke..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15cf7702580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=ac5083db84233db3
dashboard link: https://syzkaller.appspot.com/bug?extid=2afd7e71155c7e241560
compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13cf7702580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=17941c36580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/dea6ab846ab3/disk-dd6c438c.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/acebe380aa03/vmlinux-dd6c438c.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2cdbd012d0d3/bzImage-dd6c438c.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2afd7e71155c7e241560@syzkaller.appspotmail.com

BUG: memory leak
unreferenced object 0xffff8881277dc000 (size 2048):
  comm "kworker/0:2", pid 1783, jiffies 4294946784
  hex dump (first 32 bytes):
    ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00  ....1...........
    00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00  ................
  backtrace (crc 20105372):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4574 [inline]
    slab_alloc_node mm/slub.c:4898 [inline]
    __kmalloc_cache_noprof+0x371/0x480 mm/slub.c:5410
    kmalloc_noprof include/linux/slab.h:950 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    usb_alloc_dev+0x36/0x4e0 drivers/usb/core/usb.c:651
    hub_port_connect drivers/usb/core/hub.c:5470 [inline]
    hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
    port_event drivers/usb/core/hub.c:5871 [inline]
    hub_event+0x14d0/0x2180 drivers/usb/core/hub.c:5953
    process_one_work+0x277/0x5b0 kernel/workqueue.c:3302
    process_scheduled_works kernel/workqueue.c:3385 [inline]
    worker_thread+0x255/0x4a0 kernel/workqueue.c:3466
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x219/0x490 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff888128b06c00 (size 1024):
  comm "kworker/0:2", pid 1783, jiffies 4294946815
  hex dump (first 32 bytes):
    09 02 49 00 02 01 00 10 40 00 00 00 00 00 00 00  ..I.....@.......
    00 00 00 00 00 00 00 00 89 b8 69 09 81 88 ff ff  ..........i.....
  backtrace (crc b43c3ef8):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4574 [inline]
    slab_alloc_node mm/slub.c:4898 [inline]
    __do_kmalloc_node mm/slub.c:5294 [inline]
    __kmalloc_noprof+0x3b7/0x550 mm/slub.c:5307
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    usb_get_configuration+0xeb/0x2110 drivers/usb/core/config.c:940
    usb_enumerate_device drivers/usb/core/hub.c:2527 [inline]
    usb_new_device+0x1b4/0x300 drivers/usb/core/hub.c:2665
    hub_port_connect drivers/usb/core/hub.c:5567 [inline]
    hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
    port_event drivers/usb/core/hub.c:5871 [inline]
    hub_event+0x1723/0x2180 drivers/usb/core/hub.c:5953
    process_one_work+0x277/0x5b0 kernel/workqueue.c:3302
    process_scheduled_works kernel/workqueue.c:3385 [inline]
    worker_thread+0x255/0x4a0 kernel/workqueue.c:3466
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x219/0x490 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff88810c3d5a50 (size 8):
  comm "kworker/0:2", pid 1783, jiffies 4294946815
  hex dump (first 8 bytes):
    80 b8 69 09 81 88 ff ff                          ..i.....
  backtrace (crc 66af3167):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4574 [inline]
    slab_alloc_node mm/slub.c:4898 [inline]
    __do_kmalloc_node mm/slub.c:5294 [inline]
    __kmalloc_noprof+0x3b7/0x550 mm/slub.c:5307
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    usb_get_configuration+0x11d/0x2110 drivers/usb/core/config.c:945
    usb_enumerate_device drivers/usb/core/hub.c:2527 [inline]
    usb_new_device+0x1b4/0x300 drivers/usb/core/hub.c:2665
    hub_port_connect drivers/usb/core/hub.c:5567 [inline]
    hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
    port_event drivers/usb/core/hub.c:5871 [inline]
    hub_event+0x1723/0x2180 drivers/usb/core/hub.c:5953
    process_one_work+0x277/0x5b0 kernel/workqueue.c:3302
    process_scheduled_works kernel/workqueue.c:3385 [inline]
    worker_thread+0x255/0x4a0 kernel/workqueue.c:3466
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x219/0x490 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff888113c25840 (size 64):
  comm "kworker/0:2", pid 1783, jiffies 4294946817
  hex dump (first 32 bytes):
    01 00 00 00 01 00 00 00 09 04 00 00 00 01 01 30  ...............0
    00 00 00 00 0a 00 00 00 9a b8 69 09 81 88 ff ff  ..........i.....
  backtrace (crc a90fa323):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4574 [inline]
    slab_alloc_node mm/slub.c:4898 [inline]
    __do_kmalloc_node mm/slub.c:5294 [inline]
    __kmalloc_noprof+0x3b7/0x550 mm/slub.c:5307
    kmalloc_noprof include/linux/slab.h:954 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    usb_parse_configuration drivers/usb/core/config.c:826 [inline]
    usb_get_configuration+0x88f/0x2110 drivers/usb/core/config.c:1002
    usb_enumerate_device drivers/usb/core/hub.c:2527 [inline]
    usb_new_device+0x1b4/0x300 drivers/usb/core/hub.c:2665
    hub_port_connect drivers/usb/core/hub.c:5567 [inline]
    hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
    port_event drivers/usb/core/hub.c:5871 [inline]
    hub_event+0x1723/0x2180 drivers/usb/core/hub.c:5953
    process_one_work+0x277/0x5b0 kernel/workqueue.c:3302
    process_scheduled_works kernel/workqueue.c:3385 [inline]
    worker_thread+0x255/0x4a0 kernel/workqueue.c:3466
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x219/0x490 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

BUG: memory leak
unreferenced object 0xffff88811d54a500 (size 256):
  comm "kworker/0:2", pid 1783, jiffies 4294946821
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 08 a5 54 1d 81 88 ff ff  ..........T.....
    08 a5 54 1d 81 88 ff ff 20 e7 41 83 ff ff ff ff  ..T..... .A.....
  backtrace (crc 85d09f91):
    kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
    slab_post_alloc_hook mm/slub.c:4574 [inline]
    slab_alloc_node mm/slub.c:4898 [inline]
    __kmalloc_cache_noprof+0x371/0x480 mm/slub.c:5410
    kmalloc_noprof include/linux/slab.h:950 [inline]
    kzalloc_noprof include/linux/slab.h:1188 [inline]
    device_private_init drivers/base/core.c:3536 [inline]
    device_add+0x73c/0xc70 drivers/base/core.c:3587
    usb_new_device.cold+0x115/0x626 drivers/usb/core/hub.c:2695
    hub_port_connect drivers/usb/core/hub.c:5567 [inline]
    hub_port_connect_change drivers/usb/core/hub.c:5707 [inline]
    port_event drivers/usb/core/hub.c:5871 [inline]
    hub_event+0x1723/0x2180 drivers/usb/core/hub.c:5953
    process_one_work+0x277/0x5b0 kernel/workqueue.c:3302
    process_scheduled_works kernel/workqueue.c:3385 [inline]
    worker_thread+0x255/0x4a0 kernel/workqueue.c:3466
    kthread+0x14e/0x1a0 kernel/kthread.c:436
    ret_from_fork+0x219/0x490 arch/x86/kernel/process.c:158
    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[PATCH] usb: core: hcd: fix possible deadlock in rh control transfers

[Oliver Neukum]

From within the SCSI error handler memory allocations must not
trigger IO. Handling errors in UAS and the storage driver may
involve resetting a device. The thread doing the reset itself
relies on VM magic. However, that is insufficient, as resetting
a device involves resuming it. Resumption as well as resetting
involves conrol transfers to the parent of the device to be reset.
That may be a root hub. Hence usbcore must heed the flags passed
to usb_submit_urb() processing control transfers to root hubs.

The problem exist since the storage driver has been merged.

Signed-off-by: Oliver Neukum <oneukum@suse.com>
---
 drivers/usb/core/hcd.c | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 89221f1ce769..29c74ed40526 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -448,7 +448,8 @@ rh_string(int id, struct usb_hcd const *hcd, u8 *data, unsigned len)
 
 
 /* Root hub control transfers execute synchronously */
-static int rh_call_control (struct usb_hcd *hcd, struct urb *urb)
+static int rh_call_control(struct usb_hcd *hcd,
+		struct urb *urb, gfp_t mem_flags)
 {
 	struct usb_ctrlrequest *cmd;
 	u16		typeReq, wValue, wIndex, wLength;
@@ -483,8 +484,8 @@ static int rh_call_control (struct usb_hcd *hcd, struct urb *urb)
 	 * tbuf should be at least as big as the
 	 * USB hub descriptor.
 	 */
-	tbuf_size =  max_t(u16, sizeof(struct usb_hub_descriptor), wLength);
-	tbuf = kzalloc(tbuf_size, GFP_KERNEL);
+	tbuf_size = max_t(u16, sizeof(struct usb_hub_descriptor), wLength);
+	tbuf = kzalloc(tbuf_size, mem_flags);
 	if (!tbuf) {
 		status = -ENOMEM;
 		goto err_alloc;
@@ -809,12 +810,13 @@ static int rh_queue_status (struct usb_hcd *hcd, struct urb *urb)
 	return retval;
 }
 
-static int rh_urb_enqueue (struct usb_hcd *hcd, struct urb *urb)
+static int rh_urb_enqueue(struct usb_hcd *hcd,
+		struct urb *urb, gfp_t mem_flags)
 {
 	if (usb_endpoint_xfer_int(&urb->ep->desc))
 		return rh_queue_status (hcd, urb);
 	if (usb_endpoint_xfer_control(&urb->ep->desc))
-		return rh_call_control (hcd, urb);
+		return rh_call_control(hcd, urb, mem_flags);
 	return -EINVAL;
 }
 
@@ -1535,7 +1537,7 @@ int usb_hcd_submit_urb (struct urb *urb, gfp_t mem_flags)
 	 */
 
 	if (is_root_hub(urb->dev)) {
-		status = rh_urb_enqueue(hcd, urb);
+		status = rh_urb_enqueue(hcd, urb, mem_flags);
 	} else {
 		status = map_urb_for_dma(hcd, urb, mem_flags);
 		if (likely(status == 0)) {
-- 
2.54.0

Re: [PATCH] usb: core: hcd: fix possible deadlock in rh control transfers

[Alan Stern]

On Wed, Apr 29, 2026 at 12:42:06PM +0200, Oliver Neukum wrote:
> From within the SCSI error handler memory allocations must not
> trigger IO. Handling errors in UAS and the storage driver may
> involve resetting a device. The thread doing the reset itself
> relies on VM magic. However, that is insufficient, as resetting
> a device involves resuming it. Resumption as well as resetting
> involves conrol transfers to the parent of the device to be reset.
> That may be a root hub. Hence usbcore must heed the flags passed
> to usb_submit_urb() processing control transfers to root hubs.

The SCSI core prevents devices from suspending while they are in use.  
If the error handler wants to do a reset (or if a USB transfer fails and 
the driver does a reset to recover), the device won't be in runtime 
suspend at the time, and so neither will its root hub.

Besides, even if a resume was necessary, wouldn't the same VM magic that 
works for the reset thread also work for the resume?  After all, they 
will be the same thread; the usb_autoresume_device() call in 
usb_reset_device() is synchronous and it is called after 
memalloc_noio_save().

Alan Stern

Re: [PATCH] usb: core: hcd: fix possible deadlock in rh control transfers

[Oliver Neukum]

On 29.04.26 21:04, Alan Stern wrote:

> Besides, even if a resume was necessary, wouldn't the same VM magic that
> works for the reset thread also work for the resume?  After all, they

They need not be the same thread. That is the point. usb_reset_device()
does a resume. However, it is possible for this to race with another thread
doing a resume or a suspend. In that case it will block and wait for
another thread. Hence we essentially get priority inversion more or
less.

	Regards
		Oliver

Re: [PATCH] usb: core: hcd: fix possible deadlock in rh control transfers

[Alan Stern]

On Wed, Apr 29, 2026 at 09:13:59PM +0200, Oliver Neukum wrote:
> On 29.04.26 21:04, Alan Stern wrote:
> 
> > Besides, even if a resume was necessary, wouldn't the same VM magic that
> > works for the reset thread also work for the resume?  After all, they
> 
> They need not be the same thread. That is the point. usb_reset_device()
> does a resume. However, it is possible for this to race with another thread
> doing a resume or a suspend. In that case it will block and wait for
> another thread. Hence we essentially get priority inversion more or
> less.

Okay, I see.  Good point.  You should include this in the patch 
description.

Alan Stern