CVE-2026-99188 in Linux
الملخص
بحسب VulDB • 28/10/2026
في نواة لينكس، تم حل الثغرة التالية:
net: stmmac: dwmac1000: مسح مقاطعة حالة RGMII
منذ الالتزام 2e2c878a3141 ("net: stmmac: إزالة معالجة مقاطعات SGMII/RGMII/SMII")، لا يقرأ أي شيء في مسار RGMII المسجل GMAC_RGSMIIIS، لذا يبقى RGSMIIIS معلقاً خلف قناع المقاطعة GMAC_INT_MASK منذ أول تغيير للصلة. يعيد stmmac_resume() تعيين وحدة التحكم MAC (MAC) داخل دالة stmmac_hw_setup(); حيث يؤدي التعيين إلى جعل GMAC_INT_MASK يساوي 0 حتى تقوم dwmac1000_core_init() بكتابة القناع مرة أخرى، مما يتسبب في تدفق حالة المقاطعة المعلقة عبر الخط:
dwmac_dma_interrupt: unexpected status 04000000
أظهرت لقطة سجلات عند ظهور الرسالة الأولى على جهاز ODROID-HC4 ذلك:
core int_status 00000001 int_mask 00000000 pmt 00000000 rgsmiiis 0000000d
عندما يعمل خيط الاستئناف (resume thread) على وحدة المعالجة المركزية التي تتولى مقاطعة MAC، فإن هذا التدفق يستهلك الموارد ويؤدي إلى: قفل ناعم (soft lockup)، ثم إعادة تعيين بواسطة حارس النظام (watchdog reset) أو تجمد.
اقرأ المسجل GMAC_RGSMIIIS في دالة dwmac1000_irq_status() عندما لا تكون الحالة مقنعة، كما كان يفعل السائق قبل الالتزام 2e2c878a3141؛ حيث يؤدي هذا القراءة إلى مسحها.
استئناف تشغيل Wake-on-LAN من وضع s2idle مع خيط الاستئناف ومقاطعة MAC على وحدة معالجة مركزية واحدة: Helios64 (dwmac-rk)، الإصدار 7.3-rc6، تم قفله ناعماً في 3 حالات استئناف من أصل 3 دون إصلاح، وفي 0 من 10 حالة باستخدام هذا التصحيح؛ وقد عمل بشكل صحيح مع تغيير خارج الشجرة (out-of-tree) لـ dwmac-rk يحافظ على تشغيل طاقة GMAC عبر وضع السكون. جهاز ODROID-HC4 (dwmac-meson8b): 0 من 10 حالات استئناف باستخدام هذا التصحيح، و2 من 2 بدون إصلاح في بناء الإصدار 7.3-rc5. ارتفع عدد مقاطعات irq_rgmii_n بمقدار واحد لكل عملية استئناف.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.