linux-kernel - Re: [PATCH v4 1/1] xhci: Correctly handle last TRB of isoc TD on Etron xHCI host

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250205234205.73ca4ff8@foxbook>
Date: Wed, 5 Feb 2025 23:42:05 +0100
From: Michał Pecio <michal.pecio@...il.com>
To: mathias.nyman@...ux.intel.com
Cc: gregkh@...uxfoundation.org, ki.chiang65@...il.com,
 linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
 mathias.nyman@...el.com, stable@...r.kernel.org
Subject: Re: [PATCH v4 1/1] xhci: Correctly handle last TRB of isoc TD on
 Etron xHCI host

> Not giving back the TD when we get an event for the last TRB in the
> TD sounds risky. With this change we assume all old and future ETRON
> hosts will trigger this additional spurious success event.

error_mid_td can cope with hosts which don't produce the extra success
event, it was done this way to deal with buggy NECs. The cost is one
more ESIT of latency on TDs with error.

I don't know how many Etron chips Kuangyi Chiang tested, but I have
one here and it definitely has this double event bug.

These are old chips, not sure if Etron is still making them or if
anyone would want to buy (large chip, USB 3.0 only, barely functional
streams, no UAS on Linux and on Windows with stock MS drivers).

> I think we could handle this more like the XHCI_SPURIOUS_SUCCESS case
> seen with short transfers, and just silence the error message.

That's a little dodgy because it frees the TD before the HC is
completely done with it. *Probably* no problem with data buffers
(no sensible reason to DMA into them after an earlier error), but
we could overwrite the transfer ring in rare cases and IDK if it
would or wouldn't cause problems in this particular case.

Same applies to the "short packet" case existing today. I thought
about fixing it, but IIRC I ran into some differences between HCs
or out of spec behavior and it got tricky.

Maybe it would make sense to separate giveback (and freeing of the
data buffer by class drivers) from transfer ring inc_deq(). Do the
former when we reasonably believe the HC won't touch the buffers
anymore, do the latter when we are sure that it's in the next TD.

Not ideal, but easier and better than the status quo.

Regards,
Michal