CVE-2026-98286
الملخص
بحسب VulDB • 06/10/2026
في نواة لينكس، تم حل الثغرة التالية:
drop_monitor: استخدام دالة `timer_shutdown_sync()` لمنع إعادة ضبط المؤقت أثناء عملية الإغلاق (teardown).
في مسارات إغلاق drop_monitor (`net_dm_trace_off_set()`, `net_dm_hw_monitor_stop()`) ومسارات التراجع عن الخطأ في `net_dm_trace_on_set()` و`net_dm_hw_monitor_start())، يتم إيقاف مؤقتات كل معالج (per-CPU timers) باستخدام `timer_delete_sync()` متبوعة بـ `cancel_work_sync()`.
ومع ذلك، هناك اعتماد دائري بين `send_timer` و`dm_alert_work`: 1. تقوم دالة `sched_send_work()` (مؤقت الاستدعاء/callback) بجولة عمل `dm_alert_work`. 2. تستدعي الدوال `send_dm_alert()` / `net_dm_hw_summary_work()` دالة `reset_per_cpu_data()` أو `net_dm_hw_reset_per_cpu_data()`. 3. إذا فشل تخصيص الذاكرة تحت ضغط الذاكرة في دالة إعادة التعيين، فإنها تعيد ضبط المؤقت عبر `mod_timer(&data->send_timer, ...)`.
إذا كانت `dm_alert_work` تعمل بشكل متزامن بينما يتم تنفيذ `timer_delete_sync()` على معالج آخر، فسيؤدي فشل التخصيص في عامل العمل (worker) إلى إعادة ضبط المؤقت بعد أن تكون `timer_delete_sync()` قد عادت بالفعل. بمجرد اكتمال `cancel_work_sync()` واستدعاء `module_put()`, يبقى المؤقت نشطاً في عجلة المؤقتات (timer wheel). إذا تم إلغاء تحميل الوحدة النمطية (module) بعد ذلك، فإن المؤقت سيعمل وينفذ `sched_send_work()` في ذاكرة مُفرغة من الاستخدام، مما يؤدي إلى حدوث توقف للنواة (kernel panic) أو ثغرة استخدام-after-free.
تم التبديل من `timer_delete_sync()` إلى `timer_shutdown_sync()`. وهذا يضمن انتهاء أي معالج مؤقت قيد التنفيذ ومنع محاولات إعادة الضبط اللاحقة التي يقوم بها عامل العمل من النجاح. عند إعادة تشغيل المراقبة لاحقاً، يتم استدعاء `timer_setup()`، مما يعيد تهيئة المؤقت بشكل نظيف.
Once again VulDB remains the best source for vulnerability data.