linux-kernel - Re: [PATCH 0/1] usb: xhci: Queue URB_ZERO

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: <20250910233700.506a81a0.michal.pecio@gmail.com>
Date: Wed, 10 Sep 2025 23:37:00 +0200
From: Michal Pecio <michal.pecio@...il.com>
To: Mathias Nyman <mathias.nyman@...ux.intel.com>
Cc: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/1] usb: xhci: Queue URB_ZERO_PACKET as one TD

On Wed, 10 Sep 2025 02:15:19 +0200, Michal Pecio wrote:
> Generally, I tried running this with wMaxPacket=64, TRB length reduced
> to 64B (patched xhci_hcd) to force multiple TRBs in the first TD and
> with transfer lengths of 32, 64, 96, 128, 192, 256. It worked.
> 
> I can run it again tomorrow and send event-ring/trbs and epXX/trbs.

I found that my rtw88 WiFi dongle actually uses URB_ZERO_PACKET.
And it needs it - if the driver is patched to ignore the flag, ping at
certain packet size simply stops working, unless there is additional
traffic with random packet sizes to produce short transfers on the USB.

This is a high speed device. I also patched xhci to split TRBs on 512
rather than 65536 byte boundaries to get more TRBs per TD.

Result is OK I think, completion events as expected, the device works.
Note: the class driver submits URBs with misaligned data buffers.

 1 0x00000000ffed8f20: Buffer 00000000ffe9a80e length 498 TD size 2 intr 0 type 'Normal' flags b:i:i:C:s:i:e:C
 1 0x00000000ffed8f30: Buffer 00000000ffe9aa00 length 512 TD size 1 intr 0 type 'Normal' flags b:i:i:C:s:i:e:C
 1 0x00000000ffed8f40: Buffer 00000000ffe9ac00 length 14 TD size 0 intr 0 type 'Normal' flags b:i:i:c:s:i:e:C
 1 0x00000000ffed8f50: Buffer 0000000000000000 length 0 TD size 0 intr 0 type 'Normal' flags b:i:I:c:s:i:e:C
=>  0 0x00000000ff988c60: TRB 00000000ffed8f50 status 'Success' len 0 slot 2 ep 16 type 'Transfer Event' flags e:c 
 1 0x00000000ffed8f60: Buffer 00000000fff0e80e length 498 TD size 2 intr 0 type 'Normal' flags b:i:i:C:s:i:e:C
 1 0x00000000ffed8f70: Buffer 00000000fff0ea00 length 512 TD size 1 intr 0 type 'Normal' flags b:i:i:C:s:i:e:C
 1 0x00000000ffed8f80: Buffer 00000000fff0ec00 length 14 TD size 0 intr 0 type 'Normal' flags b:i:i:c:s:i:e:C
 1 0x00000000ffed8f90: Buffer 0000000000000000 length 0 TD size 0 intr 0 type 'Normal' flags b:i:I:c:s:i:e:C
=>  0 0x00000000ff988e20: TRB 00000000ffed8f90 status 'Success' len 0 slot 2 ep 16 type 'Transfer Event' flags e:c 

This was tested on some AMD, ASMedia, Renesas, NEC, VIA and Fresco.

Ånd then there is Etron. This old junk doesn't support zero-length TDs
at all, neither my version nor mainline works. No events and apparently
no USB packets either, because even if xhci is patched to "skip missed
TDs" to keep the class driver happy, ping is still getting stuck.

Maybe something to keep in mind if there is ever a bug about it.
I hope not too many people are still using this horrible HW.

Regards,
Michal