CVE-2026-80614 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
net: emac: Fix NULL pointer dereference in emac_probe
Move devm_request_irq() after devm_platform_ioremap_resource() so that dev->emacp is mapped before the interrupt handler can fire. An early interrupt hitting emac_irq() would dereference the NULL dev->emacp and crash.
Also remove redundant error message. devm_platform_ioremap_resource() already returns an error message with dev_err_probe().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel vulnerability identified in the Ethernet MAC driver, specifically within the emac_probe function, represents a critical resource initialization ordering flaw that can lead to system instability and denial of service conditions. This issue stems from an improper sequence in the hardware abstraction layer during device probing, where interrupt request lines are requested before the necessary memory-mapped I/O resources are successfully mapped into the kernel address space. The core technical defect lies in the execution order of two critical initialization functions: devm_request_irq and devm_platform_ioremap_resource. By requesting interrupts prior to mapping the hardware registers, the driver creates a race condition window where an early interrupt triggered by the network controller can occur before the device structure is fully initialized with valid pointers to its operational context.
When this premature interrupt occurs, it invokes the emac_irq handler function which attempts to access dev->emacp to manage packet transmission and reception states. Since the memory mapping has not yet completed, dev->emacp remains a NULL pointer. The subsequent dereference of this null value triggers a kernel panic due to an invalid memory address access, effectively crashing the operating system or causing severe performance degradation if handled by fault tolerance mechanisms that are not present in standard kernel configurations for such low-level hardware errors. This scenario is particularly dangerous because it can be triggered simply by plugging in a network cable or receiving traffic immediately after booting the device with this driver loaded, making it an easily exploitable condition for local denial of service attacks without requiring elevated privileges beyond those needed to load modules or trigger specific hardware states.
From a classification perspective, this vulnerability aligns closely with CWE-476, which denotes NULL Pointer Dereference, as the root cause is the attempt to access memory through a pointer that has not been properly initialized due to sequencing errors in resource acquisition. Furthermore, it relates to CWE-362 regarding Concurrent Execution using Shared Resources with Improper Synchronization, although the synchronization issue here is temporal rather than multi-threaded concurrency in the traditional sense. In terms of adversary behavior mapping under MITRE ATT&CK, this flaw could be leveraged by an attacker aiming for Impact category Denial of Service via resource exhaustion or system crash, specifically aligning with techniques that exploit software vulnerabilities to disrupt service availability on network infrastructure components.
The remediation strategy implemented involves reordering the initialization sequence within the emac_probe function to ensure strict dependency compliance between hardware register mapping and interrupt registration. By moving devm_request_irq() to execute only after devm_platform_ioremap_resource() has successfully returned a valid memory region, the driver guarantees that dev->emacp is populated with a valid pointer before any interrupt handler can be invoked by the hardware. This structural change eliminates the race condition window entirely, ensuring that all subsequent operations within the interrupt context operate on initialized and mapped resources. Additionally, the fix includes code cleanup to remove redundant error logging messages since the underlying resource mapping function already provides comprehensive diagnostic output via dev_err_probe(), thereby reducing kernel log noise without sacrificing visibility into failure modes during device initialization failures.