linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] xhci: Restrict USB4 tunnel detection for USB3 devices to Intel hosts
@ 2025-02-27 19:45 Marc Zyngier
  2025-02-27 20:20 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 3+ messages in thread
From: Marc Zyngier @ 2025-02-27 19:45 UTC (permalink / raw)
  To: linux-usb, linux-kernel, linux-arm-kernel
  Cc: Oliver Upton, Mathias Nyman, Greg Kroah-Hartman, stable

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: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Fixes: 948ce83fbb7df ("xhci: Add USB4 tunnel detection for USB3 devices on Intel hosts")
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
 drivers/usb/host/xhci-hub.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 9693464c05204..69c278b64084b 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -12,6 +12,7 @@
 #include <linux/slab.h>
 #include <linux/unaligned.h>
 #include <linux/bitfield.h>
+#include <linux/pci.h>
 
 #include "xhci.h"
 #include "xhci-trace.h"
@@ -770,9 +771,16 @@ static int xhci_exit_test_mode(struct xhci_hcd *xhci)
 enum usb_link_tunnel_mode xhci_port_is_tunneled(struct xhci_hcd *xhci,
 						struct xhci_port *port)
 {
+	struct usb_hcd *hcd;
 	void __iomem *base;
 	u32 offset;
 
+	/* Don't try and probe this capability for non-Intel hosts */
+	hcd = xhci_to_hcd(xhci);
+	if (!dev_is_pci(hcd->self.controller) ||
+	    to_pci_dev(hcd->self.controller)->vendor != PCI_VENDOR_ID_INTEL)
+		return USB_LINK_UNKNOWN;
+
 	base = &xhci->cap_regs->hc_capbase;
 	offset = xhci_find_next_ext_cap(base, 0, XHCI_EXT_CAPS_INTEL_SPR_SHADOW);
 
-- 
2.39.2


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] xhci: Restrict USB4 tunnel detection for USB3 devices to Intel hosts
  2025-02-27 19:45 [PATCH] xhci: Restrict USB4 tunnel detection for USB3 devices to Intel hosts Marc Zyngier
@ 2025-02-27 20:20 ` Greg Kroah-Hartman
  2025-02-28  9:31   ` Mathias Nyman
  0 siblings, 1 reply; 3+ messages in thread
From: Greg Kroah-Hartman @ 2025-02-27 20:20 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: linux-usb, linux-kernel, linux-arm-kernel, Oliver Upton,
	Mathias Nyman, stable

On Thu, Feb 27, 2025 at 07:45:29PM +0000, Marc Zyngier wrote:
> 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: Mathias Nyman <mathias.nyman@linux.intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: stable@vger.kernel.org
> Fixes: 948ce83fbb7df ("xhci: Add USB4 tunnel detection for USB3 devices on Intel hosts")
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
>  drivers/usb/host/xhci-hub.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
> index 9693464c05204..69c278b64084b 100644
> --- a/drivers/usb/host/xhci-hub.c
> +++ b/drivers/usb/host/xhci-hub.c
> @@ -12,6 +12,7 @@
>  #include <linux/slab.h>
>  #include <linux/unaligned.h>
>  #include <linux/bitfield.h>
> +#include <linux/pci.h>
>  
>  #include "xhci.h"
>  #include "xhci-trace.h"
> @@ -770,9 +771,16 @@ static int xhci_exit_test_mode(struct xhci_hcd *xhci)
>  enum usb_link_tunnel_mode xhci_port_is_tunneled(struct xhci_hcd *xhci,
>  						struct xhci_port *port)
>  {
> +	struct usb_hcd *hcd;
>  	void __iomem *base;
>  	u32 offset;
>  
> +	/* Don't try and probe this capability for non-Intel hosts */
> +	hcd = xhci_to_hcd(xhci);
> +	if (!dev_is_pci(hcd->self.controller) ||
> +	    to_pci_dev(hcd->self.controller)->vendor != PCI_VENDOR_ID_INTEL)
> +		return USB_LINK_UNKNOWN;

Ugh, nice catch.

Mathias, want me to just take this directly for now and not wait for you
to resend it?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] xhci: Restrict USB4 tunnel detection for USB3 devices to Intel hosts
  2025-02-27 20:20 ` Greg Kroah-Hartman
@ 2025-02-28  9:31   ` Mathias Nyman
  0 siblings, 0 replies; 3+ messages in thread
From: Mathias Nyman @ 2025-02-28  9:31 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Marc Zyngier
  Cc: linux-usb, linux-kernel, linux-arm-kernel, Oliver Upton, stable

On 27.2.2025 22.20, Greg Kroah-Hartman wrote:
> On Thu, Feb 27, 2025 at 07:45:29PM +0000, Marc Zyngier wrote:
>> 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: Mathias Nyman <mathias.nyman@linux.intel.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: stable@vger.kernel.org
>> Fixes: 948ce83fbb7df ("xhci: Add USB4 tunnel detection for USB3 devices on Intel hosts")
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
>> ---
>>   drivers/usb/host/xhci-hub.c | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
>> index 9693464c05204..69c278b64084b 100644
>> --- a/drivers/usb/host/xhci-hub.c
>> +++ b/drivers/usb/host/xhci-hub.c
>> @@ -12,6 +12,7 @@
>>   #include <linux/slab.h>
>>   #include <linux/unaligned.h>
>>   #include <linux/bitfield.h>
>> +#include <linux/pci.h>
>>   
>>   #include "xhci.h"
>>   #include "xhci-trace.h"
>> @@ -770,9 +771,16 @@ static int xhci_exit_test_mode(struct xhci_hcd *xhci)
>>   enum usb_link_tunnel_mode xhci_port_is_tunneled(struct xhci_hcd *xhci,
>>   						struct xhci_port *port)
>>   {
>> +	struct usb_hcd *hcd;
>>   	void __iomem *base;
>>   	u32 offset;
>>   
>> +	/* Don't try and probe this capability for non-Intel hosts */
>> +	hcd = xhci_to_hcd(xhci);
>> +	if (!dev_is_pci(hcd->self.controller) ||
>> +	    to_pci_dev(hcd->self.controller)->vendor != PCI_VENDOR_ID_INTEL)
>> +		return USB_LINK_UNKNOWN;
> 
> Ugh, nice catch.
> 
> Mathias, want me to just take this directly for now and not wait for you
> to resend it?

Yes, please, take it directly

Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>

Thanks
Mathias

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-02-28  9:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-27 19:45 [PATCH] xhci: Restrict USB4 tunnel detection for USB3 devices to Intel hosts Marc Zyngier
2025-02-27 20:20 ` Greg Kroah-Hartman
2025-02-28  9:31   ` Mathias Nyman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).