linux-kernel - Re: [PATCH] usb: xhci: Assume that endpoints halt as specified

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: <a5119a19-8660-4f0c-bedd-0a9a0301ef85@linux.intel.com>
Date: Tue, 11 Nov 2025 14:13:05 +0200
From: Mathias Nyman <mathias.nyman@...ux.intel.com>
To: Michal Pecio <michal.pecio@...il.com>,
 Mathias Nyman <mathias.nyman@...el.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: xhci: Assume that endpoints halt as specified

On 11/7/25 12:13, Michal Pecio wrote:
> xHCI 4.8.3 recommends that software should simply assume endpoints to
> halt after certain events, without looking at the Endpoint Context for
> confirmation, because HCs may be slow to update that.
> 
> While no cases of such "slowness" appear to be known, different problem
> exists on AMD Promontory chipsets: they may halt and generate a transfer
> event, but fail to ever update the Endpoint Context at all, at least not
> until some command is queued and fails with Context State Error. This is
> easily triggered by disconnecting D- of a full speed serial device.
> 
> Possibly similar bug in non-AMD hardware has been reported to linux-usb.
> 
> In such case, failed TD is given back without erasing from the ring and
> endpoint isn't reset. If some URB is unlinked later, Stop Endpoint fails
> and its handler resets the endpoint. On next submission it will restart
> on the stale TD. Outcome is UAF on success, or another halt on error and
> then Dequeue doesn't move and URBs are stuck. Unlinking and resubmitting
> the URBs causes unlimited ring expansion if the situation repeats.
> 
> This can be solved by ignoring Endpoint Context State and trusting that
> endpoints halt when required, except one known case in ancient hardware.
> The check for "Already resolving halted ep" becomes redundant, because
> for these completion codes we now jump to xhci_handle_halted_endpoint()
> which deals with pending EP_HALTED internally.
> 
> Link: https://lore.kernel.org/linux-usb/20250311234139.0e73e138@foxbook/
> Link: https://lore.kernel.org/linux-usb/20250918055527.4157212-1-zhangjinpeng@kylinos.cn/
> Signed-off-by: Michal Pecio <michal.pecio@...il.com>

Makes sense, I guess we can only trust hardware to update the state in
the endpoint context on specific command completions, not transfer events.

Added to queue, thanks
Mathias