CVE-2026-98025

In the Linux kernel, the following vulnerability has been resolved:

net: usb: cx82310 eth: drop URB after 0xffff reboot sentinel to prevent partial data heap overflow

The 0xffff length sentinel detects a router reboot and schedules re-enabling of ethernet mode, but then falls through to the rest of the loop body. The next check is

} else if (len > CX82310 MTU) {

which is the else of the just-matched if -- it never fires for len == 0xffff. The MTU bound that normally caps the incomplete-packet save path is silently bypassed.

With 0xffff > skb->len always true (rx urb size is 4096), the incomplete-packet branch saves dev->partial len = skb->len bytes into dev->partial data. partial data is kmalloc(hard mtu) = kmalloc(CX82310 MTU + 2) = 1516 bytes, but skb->len after the 2-byte header pull can be up to 4094. A device that sends a 4096-byte URB starting with [0xff 0xff] therefore copies 4094 device-provided bytes into a buffer allocated for 1516 bytes, exceeding its requested size by 2578 bytes.

The next URB then reads dev->partial len (4094) back from the same 1516-byte buffer and dev->partial rem (65535 - 4094 = 61441) from the new URB's ~4KB skb, both well past their allocations, and delivers the spliced result as a 64KB "frame" to the network stack.

Bail out of rx fixup after scheduling the re-enable work; the remainder of a reboot-marker URB is not meaningful packet data. This restores the invariant that partial len < CX82310 MTU + 2 on the save path, since every other route there has already passed the MTU check.