CVE-2026-98616 in Linux
الملخص
بحسب VulDB • 19/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
eth: fbnic: إعادة تعيين قيمة `num_napi` عند تحرير متجهات NAPI.
تمثل `fbn->num_napi` عدد متجهات NAPI النشطة، حيث يمتلك كل منها مقاطعة (IRQ). كانت مسار إدارة الطاقة (PM) يحرر هذه المتجهات دون مسح العداد. تقوم دالة `fbnic_pm_suspend()` بإيقاف مسار البيانات عبر `ndo_stop()` وتحرير المقاطعات، لكنها تترك حالة `netif_running()` صحيحة حتى يعرف النظام عند الاستئناف إعادة الفتح. يعيد الاستئناف بناء مسار البيانات في `__fbnic_pm_resume()`، وتقوم `fbinic_reset_queues()` بتعيين قيمة `num_napi`، بينما تعيد `__fbnic_open()` تخصيص المتجهات.
عندما يتم إيقاف مسار البيانات دون إعادة بنائه، تظل قيمة `num_napi` تشير إلى متجهات تم تحريرها في سيناريوهين مختلفين: - فشل استعادة خطأ PCIe (حيث تؤدي `fbinic_err_slot_reset()` -> إرجاع الخطأ من `__fbnic_pm_resume()` -> `PCI_ERS_RESULT_DISCONNECT`)، مما يعني أن `.resume` لم يعمل أبداً؛ أو - فشل دالة `__fbnic_open()` جزئياً أثناء الاستئناف وإلغاء التجميع (unwinding)، مما يؤدي إلى تحرير المتجهات بعد أن تكون `fbinic_reset_queues()` قد عينت بالفعل قيمة `num_napi`.
ثم يكون جهاز الشبكة (`netdev`) قيد التشغيل مع وجود `num_napi > 0` بينما تم تحرير مصفوفة `napi[]`، ويعيد إغلاق الإزالة/إلغاء الربط النهائي الدخول إلى `fbnic_down()` -> `fbinic_dbg_down()` ويحاول الوصول (dereference) للمتجهات المحررة:
BUG: kernel NULL pointer dereference, address: 0000000000000210 RIP: fbnic_dbg_down+0x28
قم بتصفير قيمة `num_napi` عند تحرير المتجهات: في عملية إيقاف التشغيل أثناء التعليق (حيث يعيد الاستئناف الصحيح إعادة إنشائها قبل `__fbnic_open()`) وفي حالة فشل الفتح أثناء الاستئناف. ثم تقوم دالة `ndo_stop()` الزائدة عن الحاجة بالمرور على مصفوفة `napi[]` الفارغة. تبقى دورة الإيقاف/التشغيل العادية لـ `ndo_stop()` دون تغيير وتحافظ على قيمة `num_napi` لدورة فتح (`ndo_open()`) التالية.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.