CVE-2026-98025net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow
Updated under an hour ago ()
Does this affect you?
It affects Linux. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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.
- CVSS
- Not yet scored
- Weakness (CWE)
- Not given
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Linux
- NVD analysis
- Received
- Record last updated
- Oct 3, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
Linux Linux linux:linux (from the name) | from ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 before d0c1ce6ef4cefe568e19afa83f543caa3c3c0873; from ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 before 0dbc89e664b4609ad672b5bdeef60df251294b8f; from ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 before 00520cdd21ea6a9b5dc8d53bbd241620d2059554; from ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 before 59bf9e94bdc49557f07d87164269daff7340f4d6; from ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 before 3bd689409bb1c93bdc6dd8ec6cbf5161bc4f0287; from ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 before 659654654eb140851467af41d610473c100c7975; from ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 before 237c9ae7145772af147e4665f158938350fa5658; from ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 before 5d50e90add8b4a978395e893e81954d19d58a7c5; and 4 more ranges | CNA record |
References
- https://git.kernel.org/stable/c/d0c1ce6ef4cefe568e19afa83f543caa3c3c0873
- https://git.kernel.org/stable/c/0dbc89e664b4609ad672b5bdeef60df251294b8f
- https://git.kernel.org/stable/c/00520cdd21ea6a9b5dc8d53bbd241620d2059554
- https://git.kernel.org/stable/c/59bf9e94bdc49557f07d87164269daff7340f4d6
- https://git.kernel.org/stable/c/3bd689409bb1c93bdc6dd8ec6cbf5161bc4f0287
- https://git.kernel.org/stable/c/659654654eb140851467af41d610473c100c7975
- https://git.kernel.org/stable/c/237c9ae7145772af147e4665f158938350fa5658
- https://git.kernel.org/stable/c/5d50e90add8b4a978395e893e81954d19d58a7c5
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.