Re: [REGRESSION] usb: core: interrupt-IN wBytesPerInterval fixup (727d045d064b) breaks RTL8153 in Lenovo dock

On 6/16/26 11:49, Amin Vakil wrote:
> 
> The following change, backported to the 7.0.x stable series, introduces
> a regression that disables the wired ethernet of a Lenovo USB-C/
> Thunderbolt dock:
> 
>   commit 727d045d064b7c9a24db3bce9c0485a382cb768b
>   usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval

Is 7.1 affected as well? Ideally try using a non-hardened kernel to keep
the downstream patches out of the way.

Ciao, Thorsten

> Hardware: Lenovo dock built-in Realtek RTL8153, enumerating as USB ID
> 17ef:721e (Lenovo rebrand of 0bda:8153), driven by r8152 through r8152-
> cfgselector. Host is an Intel laptop with xhci_hcd.
> 
> Symptom: on the patched kernel the NIC enumerates, r8152 binds and the
> netdev is created, then about one second later the device is USB-
> disconnected by r8152-cfgselector and never returns. No ethernet
> interface remains. USB, HDMI and the rest of the dock keep working, and
> plugging the cable straight into the laptop built-in NIC is unaffected.
> 
> Affected vs working (Arch linux-hardened): 7.0.11.hardened2 works,
> 7.0.12.hardened1 is broken. This commit is the only RTL8153/USB-core
> change in that delta, and it activates a code path that did not run
> before on this device (note the new wBytesPerInterval message in the
> dmesg below, absent on 7.0.11).
> 
> Why this commit: configuration 2 (CDC) of the device has an interrupt IN
> endpoint (EP 0x83) with wMaxPacketSize=16 and wBytesPerInterval=8. The
> new condition (wBytesPerInterval < wMaxPacketSize on an interrupt IN
> endpoint) now fires and rewrites wBytesPerInterval from 8 to 16. On this
> dock plus xHCI host that rewrite appears to make the device fall off the
> bus right after the cfgselector reset.
> 
> dmesg (broken kernel 7.0.12.hardened1):
>   usb 2-1.1: New USB device found, idVendor=17ef, idProduct=721e,
> bcdDevice=31.03
>   usb 2-1.1: Int endpoint with wBytesPerInterval of 8 in config 2
> interface 0 altsetting 0 ep 131: setting to 16
>   r8152-cfgselector 2-1.1: reset SuperSpeed USB device number 3 using
> xhci_hcd
>   r8152 2-1.1:1.0 (unnamed net_device) (uninitialized): Invalid header
> when reading pass-thru MAC addr
>   r8152 2-1.1:1.0 enp0s13f0u1u1: renamed from eth0
>   r8152-cfgselector 2-1.1: USB disconnect, device number 3
> 
> Relevant descriptors (lsusb -v -d 17ef:721e, captured on the working
> 7.0.11 kernel): configuration 2 (CDC), endpoint 0x83 IN Interrupt has
> wMaxPacketSize=0x0010 (16 bytes), bInterval=8, bMaxBurst=0,
> wBytesPerInterval=8 (rewritten to 16 by the new fixup). Configuration 1,
> the vendor config that r8152 actually uses, has its interrupt endpoint
> 0x83 with wMaxPacketSize=2 and wBytesPerInterval=2, which is not affected.
> 
> Reverting this commit (or just the new interrupt IN branch in drivers/
> usb/core/config.c) should restore the device. I am happy to build and
> confirm a revert, and to test any proposed fix. A quirk to skip the
> interrupt IN fixup for the RTL8153 CDC configuration, or otherwise
> narrowing the new condition, seems like the right direction.
> 
> I can provide the full dmesg and full lsusb -v output on request.
> 
> #regzbot introduced: 727d045d064b7c9a24db3bce9c0485a382cb768b
> 
> Best Regards,
> Amin Vakil