linux-kernel - Re: Deadlock in usb subsystem on shutdown, 6.18.3+

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2b4c47a5-1a5a-4e94-87d6-152da16a3b9c@rowland.harvard.edu>
Date: Wed, 14 Jan 2026 14:26:14 -0500
From: Alan Stern <stern@...land.harvard.edu>
To: Ben Greear <greearb@...delatech.com>
Cc: Hillf Danton <hdanton@...a.com>, LKML <linux-kernel@...r.kernel.org>,
	linux-usb@...r.kernel.org
Subject: Re: Deadlock in usb subsystem on shutdown, 6.18.3+

On Wed, Jan 14, 2026 at 09:51:48AM -0800, Ben Greear wrote:
> On 1/14/26 07:13, Alan Stern wrote:
...
> > > > > task:kworker/4:2     state:D stack:0     pid:1520  tgid:1520  ppid:2      task_flags:0x4288060 flags:0x00080000
> > > > > Workqueue: events __usb_queue_reset_device
> > > > > Call Trace:
> > > > >     <TASK>
> > > > >     __schedule+0x46b/0x1140
> > > > >     ? schedule_timeout+0x79/0xf0
> > > > >     schedule+0x23/0xc0
> > > > >     usb_kill_urb+0x7b/0xc0
> > > > >     ? housekeeping_affine+0x30/0x30
> > > > >     usb_start_wait_urb+0xd6/0x160
> > > > >     usb_control_msg+0xe2/0x140
> > > > >     hub_port_init+0x647/0xf70
> > > > >     usb_reset_and_verify_device+0x191/0x4a0
> > > > >     ? device_release_driver_internal+0x4a/0x200
> > > > >     usb_reset_device+0x138/0x280
> > > > >     __usb_queue_reset_device+0x35/0x50
> > > > >     process_one_work+0x17e/0x390
> > > > >     worker_thread+0x2c8/0x3e0
> > > > >     ? process_one_work+0x390/0x390
> > > > >     kthread+0xf7/0x1f0

> > Unfortunately, we have no to tell from the log you collected which host
> > controller driver encountered this problem.  Nor, unless you can
> > replicate the problem, any way to track down exactly where in that
> > driver the bug is -- or even any way to tell whether a proposed fix
> > actually solves the problem.
> > 
> > Alan Stern
> 
> The system was in the final stage of shutdown, so all we have in this case is serial
> console output.  If we set console to more verbose mode, would that provide what
> you need?

Maybe; it's hard to tell.  You'd have to enable dynamic debugging for 
the usbcore module and set the console to show debug-level messages.

> Or maybe 'dmesg' from when system boots?

I suspect that nothing from before the start of the shutdown would be 
useful.

> We can try to reproduce, but need some clues about what to provide to make progress.

The stack dump above shows that a kernel thread get stuck inside of 
usb_reset_device().  The first thing we would need to know is which 
device the thread is trying to reset.  Adding a dev_info() line near the 
start of usb_reset_device() would get us that information and you could 
capture it in the log.  (Along with that, we'd need to see the output 
from "lsusb -t".)

Knowing the device, we would know what host controller the device is 
attached to.  The trick will then be to figure what's going wrong with 
that host controller's driver.  It won't be easy, especially if the 
problem only occurs while the system is shutting down.

Alan Stern