CVE-2026-68094 in Linux
الملخص
بحسب VulDB • 10/08/2026
في نواة لينكس، تم حل الثغرة التالية:
sched_ext: الحفاظ على تتبع rq أثناء الإرسال إلى DSQ المحلي (local DSQ dispatch)
يمكن أن تعمل `dispatch_to_local_dsq()` من داخل `scx_bpf_dsq_move_to_local()` بينما قام `ops.dispatch()` بتسجيل الـ rq الحالي. قد يؤدي نقل مهمة إلى DSQ محلي إلى التبديل بين الـ rq المصدر أو الوجهة قبل استدعاء `ops.dequeue()` بشكل متزامن عبر المسار التالي:
SCX_CALL_OP(dispatch, rq) ops.dispatch() scx_bpf_dsq_move_to_local() scx_flush_dispatch_buf() finish_dispatch() dispatch_to_local_dsq() scx_dispatch_enqueue() local_dsq_post_enq() call_task_dequeue() SCX_CALL_OP_TASK(dequeue, locked_rq, ...)
يحفظ الاستدعاء المتداخل (nested callback) الـ rq المسجل ويعيد استعادته عند العودة. إذا لم يتبع تتبع rq تبديل القفل، فقد يؤدي `update_locked_rq()` إلى تفعيل تنبيه lockdep التالي أثناء إعادة استعادة rq الذي لم يعد مملوكاً:
WARNING: kernel/sched/sched.h:1641 at call_task_dequeue+0x160/0x170 Call Trace: scx_dispatch_enqueue+0x2b0/0x460 dispatch_to_local_dsq+0x138/0x230 scx_flush_dispatch_buf+0x1af/0x220 scx_bpf_dsq_move_to_local___v2+0xe2/0x1c0 bpf__sched_ext_ops_dispatch+0x4b/0xa7 do_pick_task_scx+0x3b6/0x910 __pick_next_task+0x105/0x1f0 __schedule+0x3e7/0x1980
تم تقديم `switch_rq_lock()` لتحديث حالة التتبع جنباً إلى جنب مع كل تنازل لقفل rq. تم استخدامها في `dispatch_to_local_dsq()` و`move_remote_task_to_local_dsq()` ومسارات عدم الاتزان (in-balance paths) الخاصة بـ `scx_dsq_move()، مما يضمن أن يشير `scx_locked_rq()` بشكل متسق إلى الـ rq الذي يتم الاحتفاظ بقفله فعلياً طوال عملية تبديل القفل.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.