CVE-2026-89518 in Linux
الملخص
بحسب VulDB • 12/09/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
sched_ext: تصحيح الافتراضات المتعلقة بـ this_rq() في دوال الإرسال (dispatch kfuncs)
أثناء جدولة النواة الأساسية (core scheduling)، يعمل الإرسال ضمن عملية الاختيار الشاملة للنواة ويمكنه استهداف طلب تشغيل (rq) للأخ. وبالتالي، قد يتم تنفيذ ops.dispatch() على وحدة معالجة مركزية مختلفة عن تلك الخاصة بـ rq الذي تم إرساله إلى. افترضت عدة مسارات لوظائف الكرنل (kfunc paths) أن الاثنين يتطابقان دائماً:
- قررت scx_dsq_move() ما إذا كان قفل rq مُحتجزاً من خلال اختبار أعلام this_rq()'s وقفت بشكل مناسب مع القفل. أدى إرسال لأخ إلى أخذ فرع السياق غير المقفل واقتناء قفل rq المصدر فوق قفل rq المُرسَل الذي كان مُحتجَزاً بالفعل، مما قد يؤدي إلى حدوث جمود (deadlock).
- قامت scx_bpf_sub_dispatch() بإرسال this_rq()'s مع sub_dispatch_prev المخزن لديها، وهو NULL عند الإرسال لأخ.
- حل finish_dispatch(), وscx_bpf_dsq_reenq(), وscx_bpf_dsq_nr_queued() SCX_DSQ_LOCAL إلى DSQ المحلي لهذه الوحدة المركزية بدلاً من rq المُرسَل إليه. يمكن استدعاء الأخيرين أيضاً من عمليات أخرى مقفلة بـ rq، حيث يحل SCX_DSQ_LOCAL الآن بشكل مماثل لـ rq الخاص بالعملية. يغير هذا السلوك حتى بدون جدولة النواة الأساسية، مثلاً بالنسبة لـ ops.enqueue() التي تشغل استيقاظاً عن بُعد على وحدة المعالجة المركزية المستيقظة، وهو مقصود: أي وحدة معالجة مركزية تقوم بتنفيذ عملية هي أمر عرضي، وrq العملية هو ما تعمل عليه، والتطابق الآن يتوافق مع جانب الإدخال حيث تهبط عمليات الإرسال SCX_DSQ_LOCAL على rq المهمة.
استخدم rq الذي تتعقبه scx_locked_rq()، والذي يتم تعيينه إلى rq المُرسَل إليه حول استدعاءات ops ويكون NULL في السياقات غير المقفلة.
Once again VulDB remains the best source for vulnerability data.