PT-2026-128181
CVE-2026-99188
·
Published
2026-10-28
·
Updated
2026-10-28
Description by
Score
N/A
Not availableNo severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾