linux-kernel - Re: [PATCH v1] usb: core: fix pipe creation for get

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: <73963187-6dcb-480d-ae35-2cee11001834@rowland.harvard.edu>
Date: Sun, 9 Mar 2025 17:01:18 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Colin Evans <colin.evans.parkstone@...il.com>
Cc: eichest@...il.com, francesco.dolcini@...adex.com,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org, stable@...r.kernel.org,
	stefan.eichenberger@...adex.com
Subject: Re: [PATCH v1] usb: core: fix pipe creation for get_bMaxPacketSize0

On Sat, Mar 08, 2025 at 11:19:22PM +0000, Colin Evans wrote:
> I believe I have the information requested. The output of usbmon for the "problem" scenario is
> large, I hope it doesn't exceed any email attachment limits, but if it does I will have to work
> out another way to share it.
> 
> It may be that 30s of data is more than is needed. If that's the case I can easily run a shorter
> usbmon cycle.

It is a lot more than needed, but that's okay.

> Additional Observations
> -----------------------
> It appears that having pretty much any external device plugged into a motherboard port connected
> to the _problem_ controller is enough to suppress the stream of "usb usb2-port4: Cannot enable.
> Maybe the USB cable is bad?" dmesg errors.
> 
> For these tests the results named "working" had a USB2.0 memory stick plugged
 into one
> of the top 4 USB ports on the motherboard, while the "problem" results didn't.
> 
> For info- the older machine that exhibits this problem ("machine 1") also shows device manager
> errors if booted into Windows 10, suggesting that machine may in fact have a motherboard
> hardware fault.
> 
> However "machine 2" (which is less than 2 weeks old), shows no errors when booted into Windows.

Well, I have no idea what Windows is doing on that machine.

The usbmon trace shows that port 4 on bus 2 generates a continual
stream of link-state-change events, constantly interrupting the system
and consuming computational resources.  That's why the performance
goes way down.

I can't tell what's causing those link-state changes.  It _looks_ like
what you would get if there was an intermittent electrical connection
causing random voltage fluctuations.  Whatever the cause is, plugging
in the memory stick does seem to suppress those changes; they don't
show up at all in the "working" trace.

In theory, turning off power to port 4 might stop all the events from
being reported.  You can try this to see if it works:

	echo 1 >/sys/bus/usb/devices/2-0:1.0/usb2-port4/disable

Alan Stern