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.