linux-kernel - Re: [PATCH v4] usb: xhci: quirk for data loss in ISOC transfers

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: <20250326074736.1a852cbc@foxbook>
Date: Wed, 26 Mar 2025 07:47:36 +0100
From: Michał Pecio <michal.pecio@...il.com>
To: raju.rangoju@....com
Cc: gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
 linux-usb@...r.kernel.org, mathias.nyman@...el.com,
 mathias.nyman@...ux.intel.com, stable@...r.kernel.org
Subject: Re: [PATCH v4] usb: xhci: quirk for data loss in ISOC transfers

> >> The root cause of the MSE is attributed to the ISOC OUT endpoint
> >> being omitted from scheduling. This can happen either when an IN
> >> endpoint with a 64ms service interval is pre-scheduled prior to
> >> the ISOC OUT endpoint or when the interval of the ISOC OUT
> >> endpoint is shorter than that of the IN endpoint.

To me this reads like the condition is

(IN ESIT >= 64ms && IN pre-scheduled before OUT) ||
(OUT ESIT < IN ESIT)

but I suspect it really is

(IN ESIT >= 64ms) &&
(IN pre-scheduled before OUT || OUT ESIT < IN ESIT)

because otherwise this workaround wouldn't really help:
ISOC OUT ESIT < INT IN ESIT is almost always true in practice.

Moving "either" later maybe makes it more clear:

This can happen when an IN endpoint with a 64ms service interval either
is pre-scheduled prior to the ISOC OUT endpoint or the interval of the
ISOC OUT endpoint is shorter than that of the IN endpoint.

> > This code limits interval to 32ms for Interrupt endpoints (any
> > speed), should it be isoc instead?
>
> The affected transfer is ISOC. However, due to INT EP service
> interval of 64ms causing the ISO EP to be skipped, the WA is to
> reduce the INT EP service to be less than 64ms (32ms).

What if there is an ISOC IN endpoint with 64ms ESIT? I haven't yet seen
such a slow isoc endpoint, but I think they are allowed by the spec.
Your changelog suggests any periodic IN endpoint can trigger this bug.

> > Are Full-/Low-speed devices really also affected?
> > 
> No, Full-/Low-speed devices are not affected.

The interesting question here is whether LS/FS devices with long
interval IN endpoints can disrupt a HS OUT endpoint or not, because
the patch solves the problem from the IN endpoint's side.

(I assume that SS probably has no effect on HS schedule.)

Regards,
Michal