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] [day] [month] [year] [list]

Message-ID: <737b2608-3b62-0e8b-9c78-44cca4d078be@candelatech.com>
Date: Tue, 20 Jan 2026 09:29:56 -0800
From: Ben Greear <greearb@...delatech.com>
To: Oliver Neukum <oneukum@...e.com>, Alan Stern <stern@...land.harvard.edu>
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 1/14/26 12:14, Oliver Neukum wrote:
> On 14.01.26 20:26, Alan Stern wrote:
>> 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.
> 
> Something called usb_queue_reset_device()
> 
> 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
> 
> That is a fairly rare method.
> We also know that
> "the system was un-plugged from a KVM (usb mouse & keyboard)"
> One of the few places usb_queue_reset_device() is used
> is hid_io_error()
> 
> Do you still know which port that KVM had been plugged
> into? I usually would not run a chain of logic with so
> many assumptions, but if you cannot reproduce I see
> no alternative.

Hello,

We are not able to reproduce the problem.  If we are able to reproduce,
we'll take more precise notes and provide what details we can find.

Thanks,
Ben

-- 
Ben Greear <greearb@...delatech.com>
Candela Technologies Inc  http://www.candelatech.com