CVE-2026-46110

What it actually does

This vulnerability is a NULL pointer dereference in the Linux kernel stmmac Ethernet driver receive path. When RX buffer allocation fails under memory pressure, descriptors in the DMA RX ring can remain in a dirty state with OWN=0 but no valid buffer attached. The receive loop previously treated any descriptor with OWN=0 as a completed packet, so it could attempt to process a descriptor whose buffer pointer had already been cleared. On affected systems using the stmmac driver, this can trigger a kernel panic or receive-path stall, causing loss of network availability or a full system crash. The issue affects both the conventional RX path and the zero-copy RX variant.

Why it matters to the business

Systems using affected Linux kernels with stmmac-based Ethernet hardware can be remotely or externally driven into a denial-of-service condition if network traffic and memory pressure cause RX buffer exhaustion. The practical consequence is service interruption: appliances, embedded devices, servers, gateways, or industrial systems using this driver may lose network connectivity or reboot/panic unexpectedly. The CVSS score indicates high availability impact, but EPSS is currently low and there is no known CISA KEV listing or known ransomware use, so remediation should be prioritized for exposed, high-availability, or difficult-to-reboot systems rather than treated as active mass exploitation.

How an attack unfolds

An attacker does not need authentication or user interaction, but exploitation depends on the target using the vulnerable stmmac Ethernet driver and entering a memory-starved RX refill condition. The attacker sends network traffic to the affected interface, increasing receive activity and descriptor turnover. If the system is also under memory pressure, either naturally or through workload exhaustion, stmmac_rx_refill() can fail to allocate replacement RX buffers and leave descriptors dirty. Subsequent receive processing can encounter one of these dirty descriptors, misinterpret it as a completed packet, and dereference a NULL buffer pointer. The result is typically a kernel oops or panic, terminating normal operation and causing a denial of service. In some cases the receive path may stall if descriptors cannot be refilled, resulting in loss of network receive capability without immediate compromise of confidentiality or integrity.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the stmmac fix for preventing dirty RX descriptors from being processed as valid completed descriptors in both stmmac_rx() and stmmac_rx_zc(). No exact fixed upstream or distribution package versions were provided in the input, so use the relevant Linux distribution, appliance, SoC vendor, or kernel stable branch advisory to identify the corrected package. Where immediate patching is not possible, reduce exposure by limiting untrusted network reachability to affected stmmac interfaces, applying rate limits where feasible, maintaining memory headroom, monitoring for memory exhaustion, and avoiding workloads that can drive sustained low-memory conditions on systems using this driver. For high-availability systems, schedule controlled patching and reboot validation because kernel driver fixes generally require booting into the updated kernel.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the stmmac driver and whether the active network interface is backed by stmmac/DWMAC hardware. Validate remediation by confirming the running kernel package is at or above the vendor-fixed version and that the corrected stmmac receive-path patch is present in the kernel source or changelog. Operationally, verify that the system has booted into the updated kernel, not merely installed it. Review kernel logs after upgrade for absence of NULL pointer dereference, kernel oops, panic, or receive-path stalls involving stmmac_rx or stmmac_rx_zc during normal and high-traffic testing. For embedded or appliance builds, confirm the vendor firmware image includes the patched kernel rather than only updated user-space components.

Typical attack path

1. Identify or reach a Linux system using an stmmac/DWMAC Ethernet interface and an affected kernel build.
2. Send sustained or bursty network traffic to the affected interface to increase RX descriptor processing.
3. Increase the likelihood of RX memory exhaustion by timing traffic during existing memory pressure or by contributing to resource exhaustion where possible.
4. Trigger incomplete stmmac_rx_refill() behavior, leaving RX descriptors with OWN=0 and NULL buffer pointers.
5. Cause the stmmac receive loop to process a dirty descriptor as though it contained a valid received frame.
6. Induce a kernel NULL pointer dereference, kernel panic, network receive stall, or system reboot, resulting in denial of service.

How to detect it

To assess whether exploitation or accidental triggering has already occurred, review kernel logs, persistent journal entries, crash dumps, netconsole output, pstore/ramoops records, and monitoring alerts for kernel oops or panic events involving the stmmac receive path. Focus on time windows with unexplained reboots, watchdog resets, link interruptions, packet loss, or memory pressure. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg captures, kdump vmcores, pstore entries under /sys/fs/pstore, and appliance firmware crash logs. Look for call traces referencing stmmac_rx(), stmmac_rx_zc(), stmmac_napi_poll(), DMA RX refill behavior, NULL pointer dereferences, kernel paging requests at address 0x0, or panic/oops events near high inbound traffic. Network telemetry alone is unlikely to prove exploitation because the trigger is a driver state bug rather than a unique payload; correlate inbound traffic spikes with memory allocation failures and kernel crashes on affected hardware.

• stmmac_rx
• stmmac_rx_zc
• stmmac_napi_poll
• stmmac_rx_refill
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• Call Trace:
• RIP: stmmac_rx
• RIP: stmmac_rx_zc
• PC is at stmmac_rx
• PC is at stmmac_rx_zc
• /sys/fs/pstore
• /proc/net/dev
• dwmac
• stmmaceth
• DesignWare MAC
• Synopsys DWMAC

What your security team should do

• Inventory Linux systems and appliances that use stmmac, DWMAC, Synopsys DesignWare MAC, or SoC Ethernet controllers backed by the stmmac driver.
• Prioritize patching internet-facing, untrusted-network-facing, remote-site, embedded, industrial, gateway, and high-availability systems where a network-triggered crash would have operational impact.
• Track the appropriate Linux distribution, hardware vendor, or appliance vendor advisory for the exact fixed kernel or firmware version, then deploy and reboot into that version.
• Until patched, restrict untrusted traffic to affected interfaces, apply network rate limiting where practical, and monitor for memory pressure on systems using stmmac.
• Search historical kernel logs for crashes, oops reports, or receive-path failures involving stmmac_rx, stmmac_rx_zc, NULL pointer dereferences, or DMA RX refill failures.
• Treat unexplained reboots or kernel panics on affected systems as possible denial-of-service events and preserve kernel logs, crash dumps, and netconsole output where available.
• Do not prioritize this ahead of actively exploited KEV vulnerabilities solely on exploitation likelihood, but do prioritize it for systems where network downtime or crash recovery is costly.