CVE-2026-46110

Technical summary

The stmmac driver uses a ring buffer of DMA descriptors to receive network packets, with two pointers tracking position: `cur_rx` (consumption point) and `dirty_rx` (refill point). Each descriptor cycles through states: empty (OWN=1, valid buffer), full (OWN=0, valid buffer with data), and dirty (OWN=0, NULL buffer). The vulnerability exists because stmmac_rx() only checks the OWN flag and cannot distinguish between full and dirty descriptors. When stmmac_rx_refill() fails to allocate memory, it leaves descriptors in the dirty state. If packet arrival continues, the cur_rx pointer can advance into the range of unfilled descriptors, causing the driver to dereference NULL pointers. A previous partial fix capped iteration at dma_rx_size - 1, but this doesn't prevent catching up to dirty_rx when refill operations are incomplete. The fix adds an explicit check before advancing cur_rx to detect if the next descriptor is dirty and exit the loop if so, preventing NULL dereference. The identical copy-pasted code path stmmac_rx_zc() requires the same fix.

Business impact

System stability is directly threatened. Affected Linux systems—particularly those running network-intensive workloads or deployed in memory-constrained environments—can experience kernel panics during normal operation when receive buffer allocation stalls. This can cause unplanned downtime, service interruption, and data loss if applications don't gracefully handle abrupt system shutdown. Embedded systems, IoT devices, and edge servers relying on stmmac-compatible hardware (Synopsys GMAC controllers) are especially vulnerable if they operate under sustained network load with periodic memory pressure.

Affected systems

The Linux kernel in all versions containing the stmmac driver is affected. This driver supports Synopsys GMAC and related MAC controllers commonly found in ARM SoCs, x86 network cards, and embedded systems. Specific distributions and kernel versions vary; administrators should check their kernel version against vendor advisories. Systems with limited RAM or those running memory-intensive workloads in parallel with high network throughput are at elevated risk. Not all systems using Linux are affected—only those where the stmmac driver is compiled and in use.

Exploitability

Exploitation does not require network-based code execution or special privileges. The vulnerability triggers automatically under conditions of sustained packet reception combined with memory pressure—no attacker action is necessary. However, triggering it reliably requires either crafting a specific network traffic pattern or running a memory-exhaustion scenario locally. This limits opportunistic remote exploitation but makes it a genuine denial-of-service risk in environments where an attacker can sustain high packet rates (e.g., DDoS) or where memory is already constrained. The KEV catalog does not currently list this CVE, suggesting it is not yet widely weaponized in the wild.

Remediation

Apply a kernel update that includes the fix for stmmac_rx() and stmmac_rx_zc() to add the dirty descriptor check before advancing cur_rx, and remove the previous iteration cap (dma_rx_size - 1). Until patched, mitigations are limited to operational measures: increase available system memory, tune buffer allocation parameters if configurable, monitor for sudden resets attributed to kernel panics, and reduce sustained network load where feasible. For production systems, prioritize patching over workarounds.

Patch guidance

Consult your Linux distribution (Red Hat, Canonical, SUSE, etc.) or kernel maintainer for availability of a patched kernel version. The upstream Linux kernel maintainers resolved this in the mainline repository with a commit adding an explicit dirty descriptor check in both stmmac_rx() and stmmac_rx_zc(). Verify patch details against the vendor advisory to confirm both code paths are addressed. Test the update in a non-production environment first to confirm stability with your hardware and workload.

Detection guidance

Monitor system logs for kernel panics (oops/BUG reports) that reference stmmac or the network stack, especially those mentioning NULL pointer dereference and occurring during periods of high network traffic or memory pressure. Enable kernel debugging if possible to capture stack traces pointing to stmmac_rx() or stmmac_rx_zc(). Correlate crashes with memory exhaustion events or sustained high packet rates. Automated monitoring of unplanned kernel reboots on systems known to use stmmac-compatible hardware can flag potential exploitation or environmental triggers.

Why prioritize this

This is a high-severity denial-of-service vulnerability with a CVSS score of 7.5, reflecting the lack of confidentiality or integrity impact but significant availability risk. The trigger is environmental (memory pressure + packet flow) rather than requiring sophisticated attacker craft. Any Linux system in a memory-constrained or high-traffic environment is at risk of unplanned downtime. The lack of KEV listing suggests it may not yet be actively exploited, providing a window for patching before widespread weaponization. Prioritize based on whether your systems use stmmac drivers and operate under sustained network load.

Risk score, explained

CVSS 7.5 (HIGH) reflects: network-based attack vector (AV:N), low attack complexity (AC:L), no privilege requirement (PR:N), no user interaction (UI:N), unchanged scope (S:U), no confidentiality or integrity impact (C:N/I:N), but high availability impact (A:H). The score appropriately captures a reliable denial-of-service condition without data breach risk. The lack of KEV status and active exploitation in the wild does not reduce the technical severity, only the current threat landscape urgency—this should not factor into patching decisions for affected systems.

Frequently asked questions