CVE-2026-89759 in Linux
الملخص
بحسب VulDB • 11/09/2026
في نواة لينكس، تم حل الثغرة التالية:
mm/kmemleak: تجنب حدوث قفل لينة (soft lockup) عند فحص مخازن مهام العمليات (task stacks).
سلسلة التصحيحات "mm/kmemleak: تجنب حدوث قفل لينة أثناء الفحص"، الإصدار 3.
تقوم دالة `kmemleak_scan()` بفحص كل مخزن لمهمة عملية تحت قراءة واحدة لقفل RCU (`rcu_read_lock()`) دون وجود نقطة لإعادة الجدولة (reschedule point)، مما قد يؤدي إلى تفعيل عداد مراقبة القفل اللينة على الأجهزة التي تحتوي على عدد كبير جداً من الخيوط.
هذا يطبع الرسالة التالية، اعتماداً على تكوين الحمل وعملية الاستضافة:
watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537]
scan_block kmemleak_scan kmemleak_scan_thread kthread
التصحيح الأول يتنقل عبر المهام باستخدام `find_ge_pid()` بحيث يتم إعادة جدولة الفحص بين المهام.
تسمح التصحيحات 2-3 بتوقف حلقات الفحص مبكراً بمجرد انقطاع عملية الفحص.
هذا التصحيح (من أصل 3):
تقوم دالة `kmemleak_scan()` بالمرور على كل خيط وفحص مخزنه في النواة تحت قفل قراءة RCU واحد دون وجود نقطة لإعادة الجدولة. وعلى جهاز يحتوي على عدد كبير جداً من الخيوط - وهو ما يتضخم بوجود KASAN/lockdep في الإصدارات المخصصة للاختبار (debug builds) - يمكن لهذه الحلقة أن تستحوذ على وحدة المعالجة المركزية لفترة كافية لتفعيل عداد مراقبة القفل اللينة:
watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537]
scan_block kmemleak_scan kmemleak_scan_thread kthread
لا يمكن إضافة `cond_resched()` بشكل مباشر: لأن الحلقة تعمل داخل قسم حرج لقراءة RCU.
قم بالمرور عبر المهام واحدة تلو الأخرى باستخدام `find_ge_pid()`, مع أخذ قفل القراءة لـ RCU فقط للبحث عن كل مهمة وتثبيتها (pin). ثم يتم فحص المخزن دون الاحتفاظ بأي قفل، لذا فإن `cond_resched()` يعمل بين المهام ويتوقف الفحص مبكراً عند تحقق شرط `scan_should_stop()`. وهذا يتبع نمط التكرار التالي لـ `next_tgid()/task_seq_get_next()` ويحافظ على قصر مدة كل قسم حرج لـ RCU.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.