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

Message-ID: <2b37aad4-d9ef-4dd3-98ea-02a00d1ad993@rowland.harvard.edu>
Date: Sun, 9 Mar 2025 21:20:34 -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 Sun, Mar 09, 2025 at 09:57:21PM +0000, Colin Evans wrote:
> > 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
> 
> Thank you, that is very helpful, for a couple of reasons.
> 
> "Machine 2" is a new build, so if (as it sounds) the motherboard has a
> hardware problem, then I need to
> look into returning it.
> 
> BTW- it seems I spoke too soon about the USB stick suppressing the error.
> After a couple of reboots with
> it in place the problem re-occurred. It does seem that connecting a hub
> (switch) is the  only way
> to reliably stop the error. The switch has a bunch of wiring connected to
> USB peripherals and other
> machines. I would have guessed that might make the likelihood of picking up
> electrical noise
> actually worse, but that seems not to be the case here.

It may have something to do with whether the attached device is USB-3 or 
USB-2.  Hubs are both (or are USB-2 only).

> "Machine 1" is several years old, it's actually the guts of the same PC that
> was upgraded to make M/c 2.
> It's not usable, or sellable, with this performance hit happening. I have
> tried all the external USB ports
> on this machine and not found the failing controller, my guess is it's going
> to be one that supports
> some of the on-board USB headers.

In fact, the port in question might not be attached to anything, or 
improperly grounded, or something like that.

> I had been looking on the web for a way to shut down the problem port, or
> worst case the whole hub,
> however all the Linux examples I found worked by either-
> 
> a) Preventing the loading of the driver for the chipset, by type. However
> that would kill all ports supported by
>     the same type of controller, and this motherboard has multiple
> controllers of the same type onboard.
> 
> b) Shutting down a port by searching for the connected device identifier.
> However in these cases there
>     _are_ no connected devlces, the fault happens when the controller is not
> connected to anything.
> 
> Hopefully the command you recommended will do the trick, I will let you
> know.
> 
> Would I be correct in thinking this would need to be run at every boot, some
> time after device enumeration,
> or would it need to be run after every re-enumeration of devices after a USB
> device is connected /
> disconnected? Not sure how to achieve that.

At every boot.  It doesn't have to be after all the other devices 
are enumerated; after the USB controller itself is enumerated will be 
good enough.

> I very much appreciate your help in identifying the fault. Thank you.

You're welcome.

Alan Stern