CVE-2026-97474 in Linux
الملخص
بحسب VulDB • 24/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
wifi: iwlwifi: mld: إزالة الإشعارات غير المتزامنة (async) عند حدوث خطأ في وحدة التحكم بالشبكة (NIC).
يُصلح هذا الأمر حالة توقف kernel panic أثناء فشل إعادة التكوين (reconfig):
1. لدينا اتصال BSS 2. لدينا اتصال NAN 3. يحدث خطأ في البرنامج الثابت (FW) 4. تعيد عملية إعادة التكوين استعادة اتصال BSS 5. ومع ذلك، يفشل استعادة اتصال NAN بسبب وجود خطأ في البرنامج الثابت (FW). 6. بشكل خاطئ، يتم استدعاء الدالة `ieee80211_handle_reconfig_failure` وتُعلّم جميع الواجهات بأنها "غير موجودة داخل السائق" (not-in-driver) (سيتم إصلاح ذلك في رقع مختلفة). 7. تقوم mac80211 بتحرير روابط اتصال BSS لكنها لا تخبر السائق بذلك، لأنها تعتقد أن واجهة الشبكة الافتراضية هذه (vif) غير موجودة ضمن السائق. 8. في دالة `ieee80211_stop_device`، يتم تفريغ جميع أعمال wiphy (بشكل خاطئ؟). 9. لذلك، تُنفذ الدالة `async_handlers_wk` لمعالجة إشعار الإحصائيات الذي تم استلامه بعد أن قمنا باستعادة اتصال BSS. 10. يقوم معالج الإشعارات بالوصول إلى المؤشر `fw_id_to_bss_conf[id]`، وهو الآن مؤشر معلق (dangling pointer)، لأن mac80211 قامت بالفعل بتحرير هذا الرابط في الخطوة (7).
11. عند أول وصول إلى أحد حقول الروابط، يحدث توقف مفاجئ للنظام (panic).
بينما يمكن ويجب إصلاح هذه المشكلة عن طريق إزالة استدعاء `ieee80211_handle_reconfig_failure` في الخطوة (6)، إلا أنه ليس من الجيد أيضاً الاحتفاظ بمعالجة الإشعارات القادمة من برنامج ثابت معطل (dead FW) أو التعامل معها.
نحن نقوم بإزالة الإشعارات عند إيقاف البرنامج الثابت، ولكن في حالة فشل إعادة التكوين، يتم إيقاف البرنامج الثابت متأخراً جداً، بعد معالجة الإشعارات. بالإضافة إلى ذلك، يمكن دائماً جدولة `async_handlers_wk` قبل عمل إعادة التكوين (reconfig work).
قم بإزالة الإشعارات فوراً عندما يبلغ النقل (transport) عن حدوث خطأ في وحدة التحكم بالشبكة (NIC).
VulDB is the best source for vulnerability data and more expert information about this specific topic.