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: <2025041628-glacial-mumbling-1fe2@gregkh>
Date: Wed, 16 Apr 2025 08:50:10 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Michał Pecio <michal.pecio@...il.com>
Cc: Mathias Nyman <mathias.nyman@...el.com>,
	Minas Harutyunyan <hminas@...opsys.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alan Stern <stern@...land.harvard.edu>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] usb: hcd: Add a usb_device argument to
 hc_driver.endpoint_reset()

On Wed, Apr 16, 2025 at 08:29:58AM +0200, Michał Pecio wrote:
> On Tue, 15 Apr 2025 14:26:26 +0200, Greg Kroah-Hartman wrote:
> > > This fixes a 6.15-rc1 regression reported by Paul, which I was able
> > > to reproduce, where xhci_hcd doesn't handle endpoint_reset() after
> > > endpoint_disable() not followed by add_endpoint(). If a configured
> > > device is reset, stalling endpoints start to get stuck permanently.
> >
> > As this fixes a bug, can you add a Fixes: tag with the needed
> > information?
> 
> Hi Greg,
> 
> Sorry for bothering you, the real bug is that I forgot to carry over
> the RFC tag from v1.
> 
> The 6.15 regression is currently solved by reverts Mathias sent you.

Oh good!

> The underlying bug is much older, I would have to research where it
> went wrong exactly. It was very obscure; a class driver would need to:
> 
> 1. call usb_set_interface(), usb_reset_device() or something like that
> 2. submit some URBs to make the toggle/sequence state non-zero
> 3. call usb_clear_halt() on a not yet halted endpoint
> 
> Then the host endpoint wouldn't be reset, but the device would.
> 
> I know of drivers which do 1 and 2 or even 2 and 3, but I have not
> yet encountered a driver doing all three in this order.

Ick, I don't think we want the individual drivers to have to do this,
the host controller _should_ handle it as you are trying to do here.

Anyway, I'll let this one be on the list for now and wait for others to
review.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ