linux-kernel - Re: [syzbot] [usb?] INFO: task hung in hub

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <d73e0c09-b71e-40c9-af60-86b0dd6258e8@I-love.SAKURA.ne.jp>
Date: Thu, 3 Jul 2025 10:20:37 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Hillf Danton <hdanton@...a.com>, Alan Stern <stern@...land.harvard.edu>,
        Mark Brown <broonie@...nel.org>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: syzbot <syzbot+d630bd89141124cc543e@...kaller.appspotmail.com>,
        gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
        Boqun Feng <boqun.feng@...il.com>, linux-usb@...r.kernel.org,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [usb?] INFO: task hung in hub_activate (3)

On 2025/07/03 9:09, Hillf Danton wrote:
> On Wed, 2 Jul 2025 10:34:51 -0400 Alan Stern wrote:
>> On Wed, Jul 02, 2025 at 04:05:14PM +0800, Hillf Danton wrote:
>>> On Tue, 01 Jul 2025 17:50:28 -0700
>>>> Hello,
>>>>
>>>> syzbot found the following issue on:
>>>>
>>>> HEAD commit:    1343433ed389 Add linux-next specific files for 20250630
>>>> git tree:       linux-next
>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=10d1f88c580000
>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=66357ac5b0466f16
>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=d630bd89141124cc543e
>>>> compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
>>>>
>>>> Unfortunately, I don't have any reproducer for this issue yet.
>>>>
>>>> Downloadable assets:
>>>> disk image: https://storage.googleapis.com/syzbot-assets/b005e1db0f8c/disk-1343433e.raw.xz
>>>> vmlinux: https://storage.googleapis.com/syzbot-assets/cb3aa8bfd514/vmlinux-1343433e.xz
>>>> kernel image: https://storage.googleapis.com/syzbot-assets/e01227599a09/bzImage-1343433e.xz
>>>>
>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>> Reported-by: syzbot+d630bd89141124cc543e@...kaller.appspotmail.com
>>>>
>>>> INFO: task kworker/0:0:9 blocked for more than 143 seconds.
>>>>       Not tainted 6.16.0-rc4-next-20250630-syzkaller #0
>>>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>>>> task:kworker/0:0     state:D stack:21240 pid:9     tgid:9     ppid:2      task_flags:0x4208060 flags:0x00004000
>>>> Workqueue: events_power_efficient hub_init_func2
>>>> Call Trace:
>>>>  <TASK>
>>>>  context_switch kernel/sched/core.c:5313 [inline]
>>>>  __schedule+0x16f5/0x4d00 kernel/sched/core.c:6696
>>>>  __schedule_loop kernel/sched/core.c:6774 [inline]
>>>>  schedule+0x165/0x360 kernel/sched/core.c:6789
>>>>  schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6846
>>>>  __mutex_lock_common kernel/locking/mutex.c:679 [inline]
>>>>  __mutex_lock+0x724/0xe80 kernel/locking/mutex.c:747
>>>>  device_lock include/linux/device.h:884 [inline]
>>>>  hub_activate+0xb7/0x1ea0 drivers/usb/core/hub.c:1096
>>>>  process_one_work kernel/workqueue.c:3239 [inline]
>>>>  process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3322
>>>>  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3403
>>>>  kthread+0x70e/0x8a0 kernel/kthread.c:463
>>>>  ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
>>>>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
>>>>  </TASK>
>>>
>>> Due to lockdep_set_novalidate_class(&dev->mutex) in device_initialize(),
>>> task hung instead of deadlock is reported once more.
>>>
>>> 	kworker/0:0:9		kworker/0:5:5923
>>> 	---			---
>>> 	hub_init_func2()	usb_disconnect()
>>> 				device_lock()
>>> 	device_lock()		hub_disconnect()
>>> 				hub_quiesce()
>>> 				flush_delayed_work(&hub->init_work);
>>> 	*** DEADLOCK ***
>>
>> This analysis looks right.  How would you fix the deadlock?  Make 
>> hub_disconnect do device_unlock() and device_lock() around the 
>> flush_delayed_work() call?
>>
> I will try it once a reproducer is available.

Caused by commit 9bd9c8026341 ("usb: hub: Fix flushing of delayed work
used for post resume purposes") with cc: stable.
Shouldn't we revert that commit and seek for a different approach
than wait for a reproducer?