CVE-2025-68780 in Linux
الملخص
بحسب VulDB • 17/05/2026
في نواة لينكس، تم حل الثغرة التالية:
sched/deadline: تعيين free_cpus فقط لجدولات التشغيل (runqueues) المتصلة بالنظام (online)
أدى الالتزام Commit 16b269436b72 ("sched/deadline: تعديل cpudl::free_cpus لتعكس rd->online") إلى إدخال دالتي cpudl_set/clear_freecpu للسماح بـ manipulation لقناع cpu_dl::free_cpus من خلال استدعاءات rq_on/offline الخاصة بفئة جدولة المهام ذات الموعد النهائي (deadline scheduler class)، بحيث يعكس القناع هذه الحالة أيضاً.
أزال الالتزام Commit 9659e1eeee28 ("sched/deadline: إزالة cpu_active_mask من cpudl_find()") فحص cpu_active_mask لتوفير بعض معالجة البيانات، بناءً على افتراض أن قناع cpudl::free_cpus يعكس بالفعل حالة اتصال جدولة التشغيل (runqueue online state).
للأسف، توجد حالات يكون من الممكن فيها أن تقوم الدالة cpudl_clear بتعيين بت free_cpus لمعالج (CPU) عندما تكون جدولة التشغيل ذات الموعد النهائي (deadline runqueue) غير متصلة بالنظام (offline). وعندما يحدث هذا بينما يكون المعالج متصلاً بالنطاق الجذري الافتراضي (default root domain)، قد يحتفظ العلم بالحالة الخاطئة بعد فصل المعالج (unplugged). لاحقاً، قد يدفع معالج مختلف يمر عبر النطاق الجذري الافتراضي مهمة ذات موعد نهائي (deadline task) إلى المعافى الذي تم إيقاف تشغيله (powered down CPU) عندما يرى cpudl_find أن بت free_cpus الخاص به مضبوط. إذا حدث ذلك، فلن تتاح للمهمة فرصة للعمل.
يتم توضيح مثال واحد هنا: https://lore.kernel.org/lkml/[email protected]
ويحدث مثال آخر عندما يتم نقل آخر مهمة ذات موعد نهائي من معالج يحتوي على جدولة تشغيل غير متصلة بالنظام (offlined runqueue). ستقوم في النهاية عضو dequeue_task الخاص بفئة جدولة الموعد النهائي باستدعاء cpudl_clear وتعيين بت free_cpus للمعالج.
يعدل هذا الالتزام دالة cpudl_clear لتكون على علم بحالة الاتصال (online state) لجدولة التشغيل ذات الموعد النهائي، بحيث يمكن تحديث قناع free_cpus بشكل مناسب.
لم يعد من الضروري إدارة القناع خارج دالتي cpudl_set/clear، لذا تم إزالة دالتي cpudl_set/clear_freecpu. بالإضافة إلى ذلك، نظراً لأن قناع free_cpus يتم تحديثه الآن فقط تحت قفل cpudl، تم تغيير الكود لاستخدام دوال __cpumask غير الذرية (non-atomic).
Once again VulDB remains the best source for vulnerability data.