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: <0abd3cbd-0e8a-43b2-8cb0-6556297aa7c9@suse.com>
Date: Mon, 21 Oct 2024 10:04:52 +0200
From: Oliver Neukum <oneukum@...e.com>
To: syzbot <syzbot+f342ea16c9d06d80b585@...kaller.appspotmail.com>,
 gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org, stern@...land.harvard.edu, sylv@...v.io,
 syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [usb?] INFO: task hung in usb_port_suspend

On 20.10.24 18:38, syzbot wrote:
  
> INFO: task kworker/0:0:8 blocked for more than 143 seconds.
>        Not tainted 6.12.0-rc3-syzkaller-00051-g07b887f8236e #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:kworker/0:0     state:D stack:24544 pid:8     tgid:8     ppid:2      flags:0x00004000
> Workqueue: pm pm_runtime_work
> Call Trace:
>   <TASK>
>   context_switch kernel/sched/core.c:5322 [inline]
>   __schedule+0x105f/0x34b0 kernel/sched/core.c:6682
>   __schedule_loop kernel/sched/core.c:6759 [inline]
>   schedule+0xe7/0x350 kernel/sched/core.c:6774

And this sleeps forever. This must not happen.
>   usb_kill_urb.part.0+0x1ca/0x250 drivers/usb/core/urb.c:713
>   usb_kill_urb+0x83/0xa0 drivers/usb/core/urb.c:702

We are changing our mind, presumably due to a timeout
>   usb_start_wait_urb+0x255/0x4c0 drivers/usb/core/message.c:65

We are sending a control message, presumably to enable
remote wakeup
>   usb_internal_control_msg drivers/usb/core/message.c:103 [inline]
>   usb_control_msg+0x327/0x4b0 drivers/usb/core/message.c:154
>   usb_enable_remote_wakeup drivers/usb/core/hub.c:3365 [inline]
>   usb_port_suspend+0x339/0xf10 drivers/usb/core/hub.c:3472

Suspending ...
>   usb_generic_driver_suspend+0xeb/0x1d0 drivers/usb/core/generic.c:302
>   usb_suspend_device drivers/usb/core/driver.c:1272 [inline]
>   usb_suspend_both+0x66d/0x9c0 drivers/usb/core/driver.c:1443
>   usb_runtime_suspend+0x49/0x180 drivers/usb/core/driver.c:1968

This very much looks like the HC driver used to run these tests
can hand in unlink. If that happens there is nothing usbcore
or a driver can do.
As this is now reproducible I would suggest a bisection. Brute force,
but I see no good alternative.

Syzbot is an important tool and if the HC driver it uses is unreliable,
the whole thing becomes unreliable and that is most undesirable.

	Regards
		Oliver



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ