CVE-2026-98275 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: cortina: Ack RX overrun interrupt correctly
The RX overrun interrupt is reported in interrupt status register 4, but gmac_irq() acknowledges it using the RX descriptor error bit from status register 0. For GMAC0 this writes the GMAC1 overrun bit, while for GMAC1 the shift leaves no bit in the 32-bit register.
Acknowledge the same per-port RX overrun bit that was detected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel contains a critical logic error within the Cortina Ethernet driver related to interrupt handling for receive (RX) buffer overruns. This vulnerability stems from an incorrect mapping between the hardware status registers and the acknowledgment mechanism used by the gmac_irq function. Specifically, when a receive overrun condition occurs, the hardware signals this event through bit positions in interrupt status register 4. However, the driver incorrectly attempts to acknowledge this specific interrupt source by writing to bits associated with RX descriptor errors found in status register 0. This mismatch represents a fundamental failure in aligning software logic with the silicon specification of the GMAC controller.
The operational consequences of this flaw are severe and vary depending on which MAC interface is affected. For GMAC0, the incorrect acknowledgment write inadvertently targets the overrun bit for GMAC1 due to bit shifting errors or misaligned register mappings. This means that while the driver attempts to clear an interrupt flag for one port, it actually clears a different interrupt flag belonging to another port. In scenarios involving GMAC1, the shift operation results in writing no valid bits into the 32-bit status register at all. Consequently, the actual RX overrun interrupt remains unacknowledged by the hardware because the correct bit was never written back to clear it.
This failure to properly acknowledge interrupts leads directly to persistent interrupt storms. Since the hardware does not receive the expected acknowledgment signal for the overrun condition, it continues to assert the IRQ line repeatedly. This results in high CPU utilization as the kernel spends excessive cycles handling spurious or repeated interrupts rather than processing network traffic. In worst-case scenarios, this can lead to system instability, significant latency spikes in network communication, and potential denial of service conditions where the affected Ethernet interface becomes effectively unusable due to resource exhaustion caused by the interrupt loop.
From a vulnerability classification perspective, this issue aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions, as the driver fails to correctly handle the specific exception condition signaled by the hardware. It also relates to CWE-829: Inclusion of Functionality from Untrusted Control Sources if viewed through the lens of incorrect state management derived from misinterpreted hardware signals. Within the MITRE ATT&CK framework, this behavior can be categorized under T1496: Resource Hijacking, as the system resources are consumed by unnecessary interrupt processing loops rather than legitimate application tasks.
The resolution involves correcting the gmac_irq function to ensure that it acknowledges exactly the same per-port RX overrun bit that was originally detected in status register 4. By aligning the acknowledgment write with the specific source of the interrupt, the driver correctly clears the hardware flag and stops the spurious interrupt generation. To mitigate this issue until a patch is applied or deployed, administrators should monitor system logs for excessive NIC-related interrupts and consider disabling unused Ethernet ports if they are not required to reduce the attack surface and resource consumption. Regularly updating the kernel to include fixes from upstream Linux repositories remains the most effective long-term mitigation strategy.