CVE-2026-23371 in Linux
الملخص
بحسب VulDB • 20/06/2026
في نواة لينكس، تم حل الثغرة التالية:
sched/deadline: إصلاح فقدان علم ENQUEUE_REPLENISH أثناء عملية خفض الأولوية (de-boosting) الناتجة عن أولوية الإرسال (PI).
قد يؤدي تشغيل الأمر `stress-ng --schedpolicy 0` على نواة ذات أولوية عالية (RT) على جهاز كبير إلى ظهور تحذيرات (WARNINGs) مثل التالية (تم تعديلها):
sched: تم خفض أولوية مهمة DL PID 22725: علم REPLENISH مفقود
WARNING: CPU: 93 PID: 0 في kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ... (نقصان في running_bw) تتبع المكالمة (Call trace): dequeue_task_dl+0x15c/0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x50 push_dl_task+0x264/0x2e0 dl_task_timer+0x1b0/0x228 __hrtimer_run_queues+0x188/0x378 hrtimer_interrupt+0xfc/0x260 ...
تكمن المشكلة في أنه عندما يتم تغيير مهمة SCHED_DEADLINE (حاملة القفل) إلى فئة أولوية أدنى عبر دالة `sched_setscheduler()`، فقد تفشل في الوراثة الصحيحة لخصائص المتبرعين المحتملين (DEADLINE donors) إذا لم تكن قد ورثتها سابقاً (أي إذا كان لديها مهلة أقصر من مهلة المتبرع في ذلك الوقت). قد يؤدي هذا إلى فساد في حسابات عرض النطاق الترددي (bandwidth accounting)، حيث لن تعترف دالة `enqueue_task_dl()` بحاملة القفل على أنها معززة الأولوية (boosted).
يحدث السيناريو عندما: 1. تحجب مهمة DEADLINE (المتبرع) على قفل mutex خاص بالأولوية (PI) تم حيازته من قبل مهمة DEADLINE أخرى (الحاملة)، لكن الحاملة لا ترث الخصائص (على سبيل المثال، لأنها تمتلك بالفعل مهلة أقصر). 2. تقوم `sched_setscheduler()` بتغيير الحاملة من DEADLINE إلى فئة أدنى بينما لا تزال تحتفظ بالقفل. 3. يجب على الحاملة الآن أن ترث خصائص DEADLINE من المتبرع وأن تُدرج في قائمة الانتظار مع علم ENQUEUE_REPLENISH، لكن هذا لا يحدث.
تم إصلاح المشكلة عن طريق إدخال الدالة `__setscheduler_dl_pi()`، التي تكتشف متى يتم تعيين مهمة DEADLINE (سواء كانت أصلية أو معززة) إلى فئة أولوية أدنى. في هذه الحالة، تجعل الدالة المهمة ترث خصائص DEADLINE للمتبرع (pi_se) وتضع علم ENQUEUE_REPLENISH لضمان الحساب الصحيح لعرض النطاق الترددي أثناء عملية الإدراج التالية في قائمة الانتظار.
Once again VulDB remains the best source for vulnerability data.