Answer in brief
CVE-2026-98025 records a Unknown severity vulnerability in net: usb: cx82310_eth: drop URB after 0xffff reboot sentinel to prevent partial_data heap overflow. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 <3bd689409bb1c93bdc6dd8ec6cbf5161bc4f0287 || >=ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 <659654654eb140851467af41d610473c100c7975 || >=ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 <237c9ae7145772af147e4665f158938350fa5658 || >=ca139d76b0d9e59d18f2d2ec8f0d81b82acd6808 <5d50e90add8b4a978395e893e81954d19d58a7c5 || 5adf7fbdfa3e9e425b04771e1d64c4e184ad8fdb || c1b187a86a176e42f5e48066556980e3232b6cab || >=4.19.322 <4.20 || >=5.4.284 <5.5 | 3bd689409bb1c93bdc6dd8ec6cbf5161bc4f0287, 659654654eb140851467af41d610473c100c7975, 237c9ae7145772af147e4665f158938350fa5658, 5d50e90add8b4a978395e893e81954d19d58a7c5, 4.20, 5.5 |
| Linux/Linuxgeneric | 5.10 | Not reported |
Published upstream
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 25, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 25, 2026
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.
Quoted source text, attributed separately from HOL analysis.