VulnerabilityPublished 28 Oct 2026

CVE-2026-99188: Linux kernel · net: stmmac: dwmac1000: clear the RGMII status interrupt

Affects Linux kernelSource CVE Database V5

Not known to be exploited : upgrade to affc6d572935282ef9ab1e0b790cbc31e5ad8bca or aa07285705f8d5bac464eb1c5b7412f8e88b91e1 when convenient.

Data as of 28 Oct 2026, 10:58 UTC

Severity

Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

Patch: Available – fixed in affc6d572935282ef9ab1e0b790cbc31e5ad8bca, aa07285705f8d5bac464eb1c5b7412f8e88b91e1

Exploitation evidence

Disclosed: evidence found.
CVE published 28 Oct 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade Linux kernel to affc6d572935282ef9ab1e0b790cbc31e5ad8bca or aa07285705f8d5bac464eb1c5b7412f8e88b91e1.

Affected software

Product	Affected	Fixed in
LinuxLinux	Affected ≥ 2e2c878a314175a4c3b76ee3be455f543438f472, < affc6d572935282ef9ab1e0b790cbc31e5ad8bca	Fixed in affc6d572935282ef9ab1e0b790cbc31e5ad8bca
LinuxLinux	Affected ≥ 2e2c878a314175a4c3b76ee3be455f543438f472, < aa07285705f8d5bac464eb1c5b7412f8e88b91e1	Fixed in aa07285705f8d5bac464eb1c5b7412f8e88b91e1
LinuxLinux	Affected =6.19	Fixed in–

Description

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.

References

Community reviews

Loading reviews…