]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
xhci: Restrict USB4 tunnel detection for USB3 devices to Intel hosts
authorMarc Zyngier <maz@kernel.org>
Thu, 27 Feb 2025 19:45:29 +0000 (19:45 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 13 Mar 2025 12:02:10 +0000 (13:02 +0100)
commit39c2b2767e73fc0b940de7816a3b118b9f8808ce
treee1372ae42283bcdcd5cc6169ffa02e49b7f4e01e
parent7c1f254c07439e89eadfffe5a9b26da533536ab0
xhci: Restrict USB4 tunnel detection for USB3 devices to Intel hosts

commit 487cfd4a8e3dc42d34a759017978a4edaf85fce0 upstream.

When adding support for USB3-over-USB4 tunnelling detection, a check
for an Intel-specific capability was added. This capability, which
goes by ID 206, is used without any check that we are actually
dealing with an Intel host.

As it turns out, the Cadence XHCI controller *also* exposes an
extended capability numbered 206 (for unknown purposes), but of
course doesn't have the Intel-specific registers that the tunnelling
code is trying to access. Fun follows.

The core of the problems is that the tunnelling code blindly uses
vendor-specific capabilities without any check (the Intel-provided
documentation I have at hand indicates that 192-255 are indeed
vendor-specific).

Restrict the detection code to Intel HW for real, preventing any
further explosion on my (non-Intel) HW.

Cc: stable <stable@kernel.org>
Fixes: 948ce83fbb7df ("xhci: Add USB4 tunnel detection for USB3 devices on Intel hosts")
Signed-off-by: Marc Zyngier <maz@kernel.org>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20250227194529.2288718-1-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/usb/host/xhci-hub.c