CVE-2026-45940

What it actually does

This is a Linux kernel denial-of-service flaw in the stmmac Ethernet driver receive path for GMAC4 hardware when split-header reception is enabled. In rare descriptor layouts, the driver incorrectly assumes the second receive buffer is fully populated when the first descriptor is not the last descriptor. That causes an incorrect buffer-length calculation and can lead to invalid DMA/cache synchronization and a kernel oops in the network receive softirq path. Successful triggering can crash the kernel or destabilize networking, impacting system availability; there is no indicated confidentiality or integrity impact.

Why it matters to the business

Affected systems using the Linux stmmac driver on relevant GMAC4 Ethernet hardware may crash or become unstable when the vulnerable receive path is exercised. For appliances, embedded Linux devices, gateways, industrial systems, or servers that rely on this NIC driver, the main risk is unexpected outage, service interruption, watchdog reboot, or loss of network connectivity. The vulnerability is not currently in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported public exploit maturity, so urgency is primarily driven by whether the organization operates exposed or mission-critical devices using this driver and split-header mode.

How an attack unfolds

An attacker first needs a system running an affected Linux kernel with the stmmac driver on GMAC4-class hardware and split-header receive behavior enabled. Under the currently assigned scoring, exploitation requires local low-privileged access; a local user or process would attempt to drive network receive activity through the affected interface in a way that causes the hardware/driver to produce the rare descriptor state where the first descriptor does not contain the expected payload in buf2. The vulnerable driver then miscalculates the length associated with a subsequent descriptor, performs DMA synchronization against an invalid or incorrect memory range, and the kernel faults in the receive polling path. The practical result is a kernel oops, panic, reboot, or loss of network service. Reliable remote exploitation has not been established from the provided data, but systems that process untrusted network traffic on affected stmmac interfaces should still prioritize vendor kernel updates because the failure occurs in packet receive handling.

How to fix it

Apply a Linux kernel update from the operating system, appliance, or board vendor that includes the stmmac fix using the RDES3 PL bit-field for all descriptors. No exact fixed package versions were provided, so remediation should be tracked through vendor advisories, stable kernel changelogs, or distribution security updates referencing the stmmac split-header oops fix. Reboot into the corrected kernel after installation. Where immediate patching is not possible, reduce exposure by disabling split-header/header-split receive functionality if the platform or vendor supports doing so, moving critical workloads off affected stmmac GMAC4 interfaces, limiting untrusted local access, and ensuring watchdog/restart procedures are in place for systems where availability is critical. Treat mitigations as temporary; the durable fix is a patched kernel or vendor firmware/software image containing the corrected driver logic.

How to confirm the fix worked

Confirm that the running kernel is the updated vendor-fixed build, not only that the package is installed. Validate with kernel package inventory, `uname -a`, distribution changelogs, and vendor release notes for the stmmac split-header receive-path fix. Confirm the affected interface uses or does not use the stmmac driver by checking driver binding information such as `ethtool -i <interface>` or sysfs driver links. Review boot and kernel logs after update to ensure no recurring oops signatures appear in `stmmac_napi_poll_rx`, `dma_direct_sync_single_for_cpu`, or related network receive softirq functions. For high-assurance validation, run controlled network receive stress testing on a patched non-production representative device and verify that the system remains stable without kernel oops or panic messages.

Typical attack path

1. Identify a Linux system using the stmmac Ethernet driver on affected GMAC4 hardware.
2. Confirm or induce use of the split-header receive path where supported by the driver and hardware.
3. Obtain local low-privileged execution, or otherwise generate traffic patterns through the affected interface if the deployment exposes the receive path to untrusted traffic.
4. Exercise the receive path until the rare descriptor condition occurs where buf2 is not populated as the vulnerable code expects.
5. Trigger the incorrect buffer-length calculation and invalid DMA/cache synchronization.
6. Cause a kernel oops, panic, reboot, or network-service disruption.

How to detect it

Because this is an availability flaw in kernel receive handling, evidence of prior exploitation will usually appear as crash artifacts rather than traditional compromise indicators. Review persistent kernel logs, `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, serial console logs, appliance event logs, watchdog reset records, kdump/vmcore files, and hypervisor or out-of-band management reset histories. Look for kernel oops or panic events with call traces involving the stmmac receive polling path, DMA synchronization, network softirqs, and cache invalidation functions. Correlate crashes with bursts of inbound traffic, local user activity that generated network traffic, interface resets, or watchdog reboots. Absence of these artifacts does not prove the vulnerability was never triggered, especially if kernel logs are volatile or crash dumps are disabled. There are no known attacker-specific payload strings, files, registry keys, or malware artifacts derivable from the vulnerability details.

• Unable to handle kernel paging request
• stmmac_napi_poll_rx
• dma_direct_sync_single_for_cpu
• __dma_sync_single_for_cpu
• dcache_inval_poc
• net_rx_action
• handle_softirqs
• kernel oops
• Call trace:
• RDES3
• split header
• stmmac

What your security team should do

• Inventory Linux systems, appliances, embedded devices, and network-facing platforms that use the stmmac Ethernet driver, especially GMAC4-based hardware.
• Prioritize patching for devices that are mission-critical, remotely managed, difficult to physically recover, or exposed to untrusted network traffic.
• Obtain the fixed kernel or firmware image from the responsible OS, appliance, or hardware vendor and schedule a reboot into the corrected build.
• If patching is delayed, disable split-header/header-split receive behavior where supported and document the operational impact of doing so.
• Restrict local shell or code-execution access on affected systems because the assigned attack vector requires low-privileged local access.
• Enable persistent kernel logging, kdump, or crash collection on critical systems so exploitation or recurrence can be distinguished from unrelated hardware faults.
• Create SOC detections for the kernel oops stack signatures associated with the stmmac receive path and alert on repeated crashes or watchdog reboots.
• Monitor vendor advisories for exact fixed versions because no package-specific fixed versions were provided in the input.