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: <d06367d4-9bbd-4a8f-a6cf-e95576aa974a@amd.com>
Date: Thu, 27 Mar 2025 16:32:01 +0530
From: "Rangoju, Raju" <raju.rangoju@....com>
To: Michał Pecio <michal.pecio@...il.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



On 3/27/2025 3:04 PM, Michał Pecio wrote:
> On Thu, 27 Mar 2025 12:08:53 +0530, Rangoju, Raju wrote:
>>> 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.
>>
>> If such an endpoint is implemented, it could theoretically contribute
>> to scheduling conflicts similar to those caused by INT endpoints in
>> this context. However, our observations and testing on affected
>> platforms primarily involved periodic IN endpoints with service
>> intervals greater than 32ms interfering with ISOC OUT endpoints.
> 
> In such case it would make sense to drop the check for
> usb_endpoint_xfer_int(&ep->desc)
> and rely on existing (xfer_int || xfer_isoc) in the outer 'if'.
>

Got it. I'll address this in subsequent patch.

>> I'm not completely sure about this corner case if HS OUT endpoints
>> can inadvertently get affected when co-existing with long-interval
>> LS/FS IN endpoints. Our IP vendor confirmed that LS/FS devices are
>> not affected.
> 
> There is also a third case of a FS device behind an external HS hub.
> The device will look like FS to this code here, but the xHC will need
> to schedule HS transactions to service it.

In that case, the original code I provided in this patch doesn't include 
a check for 'udev->speed' and is applicable to FS devices as well. I 
think this code should remain unchanged to properly address the third 
scenario you mentioned.

> 
> Regards,
> Michal


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ