CVE-2026-99188 in Linux
Summary
by MITRE • 10/28/2026
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: dwmac1000: clear the RGMII status interrupt
Since commit 2e2c878a3141 ("net: stmmac: remove SGMII/RGMII/SMII interrupt handling") nothing on the RGMII path reads GMAC_RGSMIIIS, so RGSMIIIS stays pending behind GMAC_INT_MASK from the first link change on. stmmac_resume() resets the MAC in stmmac_hw_setup(); the reset sets GMAC_INT_MASK to 0 until dwmac1000_core_init() writes the mask again, and the pending status storms the line:
dwmac_dma_interrupt: unexpected status 04000000
A register dump at the first message on ODROID-HC4 showed it:
core int_status 00000001 int_mask 00000000 pmt 00000000 rgsmiiis 0000000d
When the resume thread runs on the CPU that takes the MAC interrupt, the storm starves it: a soft lockup, then a watchdog reset or a hang.
Read GMAC_RGSMIIIS in dwmac1000_irq_status() when the status is not masked, as the driver did before 2e2c878a3141; the read clears it.
Wake-on-LAN resume from s2idle with the resume thread and the MAC interrupt on one CPU: Helios64 (dwmac-rk), 7.3-rc6, soft-locked in 3 of 3 resumes without a fix and in 0 of 10 with this patch; it ran with an out-of-tree dwmac-rk change that keeps the GMAC powered across suspend. ODROID-HC4 (dwmac-meson8b): 0 of 10 with this patch, 2 of 2 without a fix on a 7.3-rc5 build. irq_rgmii_n went up by one per resume.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/28/2026
The Linux kernel driver for Synopsys DesignWare MAC Ethernet controllers contains a critical interrupt handling flaw within the dwmac1000 subsystem that leads to system instability during power state transitions. This vulnerability stems from an incomplete code cleanup performed in commit 2e2c878a3141, which removed specific SGMII and RGMII interrupt handling logic but inadvertently failed to preserve the necessary register reads required to clear pending status bits. Specifically, the GMAC_RGSMIIIS register, which holds the status for Reduced Gigabit Media Independent Interface events, is no longer read by any component of the driver after this change. Consequently, once a link state change occurs and sets a bit in this register, that interrupt request remains permanently asserted because there is no mechanism to acknowledge or clear it from the hardware level.
The operational impact becomes most severe during system resume operations, particularly when transitioning from low-power states such as s2idle with Wake-on-LAN enabled. During the resume sequence, the stmmac_resume function invokes stmmac_hw_setup, which performs a MAC reset that temporarily sets GMAC_INT_MASK to zero while dwmac1000_core_init is preparing to reconfigure interrupt masks. Because the RGSMIIIS register retains its pending status from previous link changes and remains masked during this critical window, the hardware continues to assert the interrupt line even though the driver is not yet listening for it. This results in an immediate storm of interrupts upon resumption, as evidenced by unexpected status codes like 04000000 appearing in DMA interrupt handlers.
This continuous stream of unhandled interrupts creates a severe resource exhaustion scenario on the CPU core responsible for processing MAC interrupts. The constant interruption prevents the kernel scheduler from executing normal tasks, leading to soft lockups where the system becomes completely unresponsive. In many observed cases across various hardware platforms such as ODROID-HC4 and Helios64, this condition triggers watchdog resets or results in a complete hang of the operating system. Testing indicates that without mitigation, resume operations fail consistently on affected devices, whereas applying the fix eliminates these failures entirely by ensuring the interrupt is properly cleared before it can cause contention.
The technical root cause aligns with CWE-754: Improper Check for Unusual or Exceptional Conditions, as the driver fails to account for pending hardware state that persists across reset boundaries. From a defensive perspective, this also reflects CWE-829: Inclusion of Functionality from Untrusted Control Sources if one considers the reliance on correct interrupt masking sequences during initialization phases. The vulnerability is further contextualized by MITRE ATT&CK technique T1053 Scheduled Task/Job, as the recurring nature of the resume event acts like a scheduled trigger for this denial-of-service condition, though it is unintentional rather than malicious.
To resolve this issue, the driver must explicitly read the GMAC_RGSMIIIS register within the dwmac1000_irq_status function when the interrupt status indicates that RGMII events are pending but not yet masked by the current configuration. Reading this register serves as the hardware-specific acknowledgment mechanism required to clear the bit and stop the interrupt line from asserting further. This restores the behavior present prior to the problematic commit, ensuring that link change notifications do not accumulate into a persistent state that overwhelms the CPU during critical power management transitions. System administrators should ensure their kernels are updated with this patch applied to prevent service interruptions on embedded devices relying on these Ethernet controllers for network connectivity after suspend cycles.