linux-kernel - Re: xhci: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.

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: <3efb52b8-0974-4125-a344-00f459fbe4e4@rowland.harvard.edu>
Date: Mon, 7 Apr 2025 12:11:32 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Michał Pecio <michal.pecio@...il.com>
Cc: Paul Menzel <pmenzel@...gen.mpg.de>,
	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Mathias Nyman <mathias.nyman@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-usb@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: xhci: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep
 state.

On Mon, Apr 07, 2025 at 07:49:05AM +0200, Michał Pecio wrote:
> On Sun, 6 Apr 2025 15:26:41 -0400, Alan Stern wrote:
> > I'd guess that you're seeing the result of the
> > 
> > 		usb_disable_interface(udev, intf, true);
> > 
> > call in usb_reset_and_verify_device().  This call is made following
> > the actual reset, as part of the procedure for putting everything
> > back to the way it was before the reset.
> 
> Your guess is right. I added dump_stack() to those calls.
> 
> The bug is triggered by this function calling usb_disable_interface()
> and usb_enable_interface() after usb_hcd_alloc_bandwidth().
> 
> These two issue endpoint_disable() and endpoint_reset() to the HCD and
> xhci_hcd appears to be confused about the intent of the former, because
> it clears host_ep->hcpriv, breaking all future endpoint_reset() calls.
> 
> Since 6.15, this call informs xhci_hcd that device endpoint has been
> cleared and pending URBs can be started, so this isn't working now.
> 
> 
> BTW, that's not a corner of the driver which I'm very familiar with,
> but AFAIU this disable/enable sequence is pointless for xHCI if done
> on freshly created endpoints. It would only wait for clearing TT to
> finish (there should be none) and issue some commands to clear the
> toggle/sequence state (which should be blank).

It looks like the purpose of the calls to usb_disable_interface() and 
usb_enable_interface() in usb_reset_device() is to update the data 
structures in the core and to notify HC drivers that ignore the 
reset_device callback.

The fact is, there are lots of operations carried out by the core which 
can affect the HC drivers, and I don't think anybody has audited the 
callbacks used to communicate between the two.  I don't even know offhand 
if any HC drivers besides xhci-hcd uses these callbacks.

It would be a good idea to check whether this stuff should be updated and 
improved.

Alan Stern