CVE-2026-31649

What it actually does

The flaw is an integer underflow in the Linux kernel stmmac Ethernet driver transmit path when operating in descriptor chain mode. The driver decides that a packet is jumbo-sized using the total socket buffer length, but later subtracts a fixed buffer size from only the packet’s linear data length. If the linear portion is smaller than the buffer size while the total packet is larger because of page fragments, the unsigned subtraction wraps to a very large value. The transmit loop can then iterate far beyond the actual packet buffer and pass out-of-bounds kernel memory addresses to dma_map_single(). On systems without an IOMMU, which are common for stmmac-based SoCs, this can cause the Ethernet DMA engine to read unintended kernel memory and transmit it, and in some conditions may also destabilize or corrupt memory through invalid DMA behavior.

Why it matters to the business

Affected Linux-based appliances, embedded systems, routers, industrial devices, NAS platforms, gateways, and other systems using the stmmac Ethernet driver may be exposed to kernel memory disclosure, crashes, or device instability. Successful exploitation could leak sensitive in-memory data, disrupt network availability, or undermine the integrity of the device. Although EPSS is currently low and no known exploited status is reported, the CVSS severity is critical because exploitation can be network-triggered in plausible forwarding, bridging, tunneling, or jumbo-frame traffic scenarios without authentication.

How an attack unfolds

An attacker needs to cause a vulnerable system using the stmmac driver to transmit a specially shaped large packet through the affected interface. The packet must have a total length large enough to be treated as a jumbo frame, while its linear skb head length remains smaller than the driver’s fixed buffer threshold and the remaining data is held in page fragments. This can occur through crafted traffic that the device forwards, bridges, tunnels, responds to, or otherwise causes to be emitted. When the kernel transmit path processes that skb in stmmac chain mode, the driver underflows the length calculation and believes there is a huge amount of linear data to map. It repeatedly maps addresses beyond the packet buffer for DMA. On systems lacking IOMMU protection, the NIC may DMA-read arbitrary adjacent kernel memory and place those bytes on the wire as transmitted frame data, creating a kernel memory disclosure primitive and potentially causing device instability or corruption.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the stmmac fix for the jumbo_frm() chain-mode integer underflow. Because no exact fixed package versions were provided, use distribution, device-vendor, or upstream stable kernel advisories to identify the first patched release for the affected branch. Where immediate patching is not possible, reduce exposure by disabling jumbo frames on stmmac interfaces, avoiding MTUs above the standard Ethernet size unless required, and disabling transmit offloads that create fragmented/skb paged transmit buffers where operationally acceptable, such as TSO, GSO, and scatter-gather using ethtool. Prefer enabling IOMMU/DMA remapping where supported, as it can limit arbitrary DMA access. For high-risk appliances, embedded systems, or externally reachable routers/bridges, consider isolating affected interfaces or temporarily moving traffic to non-affected NICs until patched.

How to confirm the fix worked

Confirm whether the system uses the stmmac driver by checking loaded modules, kernel logs, interface driver information, and device tree/PCI platform bindings. Validate remediation by confirming the running kernel contains the upstream or vendor patch that clamps the jumbo transmit buffer length before subtracting it. Check that affected systems have been rebooted into the patched kernel, not merely had packages installed. Verify mitigations by confirming jumbo MTU is disabled or reduced, and that relevant transmit offloads are disabled where mitigation is required. Practical exposure testing should be performed only in a controlled lab: generate large fragmented skb transmissions through the stmmac interface and confirm the patched system does not produce DMA mapping anomalies, kernel warnings, crashes, or unexpected frame data beyond the intended packet payload.

Typical attack path

1. Identify a Linux-based target whose network interface uses the stmmac/dwmac Ethernet driver and supports jumbo frames or large offloaded/skb-fragmented transmissions.
2. Determine a network path that causes the target to transmit attacker-influenced large packets, such as routing, bridging, tunneling, proxying, or protocol responses.
3. Send traffic crafted so the resulting transmitted skb has a small linear head but a large total length stored in page fragments.
4. Trigger the vulnerable stmmac chain-mode jumbo transmit path.
5. Cause the unsigned length subtraction to underflow and the transmit loop to map memory beyond the skb buffer for DMA.
6. Capture anomalous transmitted Ethernet frames or observe crashes/instability, depending on whether memory is disclosed, invalid DMA occurs, or the device faults.

How to detect it

There are no public, unique exploit indicators for this vulnerability, and successful memory disclosure may leave little or no host-side evidence on IOMMU-less systems. Detection should focus on exposure plus anomalies. Review kernel logs from dmesg, journald, syslog, and persistent crash logs for stmmac/dwmac transmit errors, DMA mapping warnings, IOMMU faults, TX timeouts, interface resets, page faults, or kernel oops events around periods of large or jumbo traffic. On the network side, inspect packet captures from affected interfaces for malformed or unusually large outbound Ethernet frames, repeated jumbo transmissions, frame payloads containing unexpected kernel-like data, or data beyond the expected application payload. If the system has DMA-API debugging, IOMMU fault logging, crash dumps, or watchdog telemetry enabled, search those sources for invalid DMA mappings, bus faults, or NIC reset events. For appliances and embedded systems, also review vendor diagnostic logs and firmware crash reports for stmmac, dwmac, DMA, or Ethernet MAC driver faults.

• stmmac
• dwmac
• stmmaceth
• DMA-API
• dma_map_single
• IOMMU fault
• TX timeout
• transmit timeout
• NETDEV WATCHDOG
• kernel BUG
• kernel oops
• Unable to handle kernel paging request
• eth%d: Reset adapter
• stmmac: DMA
• dwmac: DMA

What your security team should do

• Inventory Linux systems, embedded devices, routers, gateways, industrial controllers, and appliances that use the stmmac/dwmac Ethernet driver.
• Prioritize patching systems that forward, bridge, route, tunnel, or otherwise transmit untrusted network traffic through stmmac interfaces, especially where jumbo frames are enabled.
• Apply vendor kernel updates or upstream stable kernels containing the stmmac jumbo_frm() chain-mode underflow fix, then reboot and verify the running kernel version/build.
• Until patched, disable jumbo frames and unnecessary transmit offloads such as TSO, GSO, and scatter-gather on affected interfaces where operationally feasible.
• Enable IOMMU/DMA remapping on platforms that support it, and validate that it is active for the affected NIC.
• Monitor for kernel DMA, stmmac, dwmac, transmit timeout, page fault, and interface reset messages that may indicate attempted exploitation or instability.
• Capture and inspect anomalous oversized outbound frames from affected interfaces if exploitation is suspected, especially frames containing unexpected memory-like data beyond legitimate payloads.
• Track vendor advisories because fixed versions vary across Linux distributions, BSPs, embedded firmware, and long-term support kernel branches.