CVE-2026-98220 in Linux
الملخص
بحسب VulDB • 07/10/2026
في نواة لينكس، تم إصلاح الثغرة التالية:
sched_ext: تصحيح الوصول إلى مؤشر NULL (NULL sched deref) في مسارات الخطأ الخاصة بـ kfunc sub-sched
عندما يكون لدى الجدول الرئيسي (root scheduler) جداول فرعية (sub-scheds) متصلة به، فإن أغطية الوظائف المتوافقة مع النظام (COMPAT kfunc wrappers) `scx_bpf_select_cpu_and()` و `scx_bpf_dsq_insert_vtime()` ترفض الاستدعاء وتبلغ الجدول الخاص بـ @p:
scx_error(scx_task_sched(p), "... must be used");
هذه الأغطية قابلة للوصول عبر مهام لا تمتلك أي جدول. تقع `scx_bpf_select_cpu_and()` ضمن مجموعة kfunc الخاصة باختيار المعالج (select_cpu)، والتي يفتحها `scx_kfunc_context_filter()` لبرامج BPF_PROG_TYPE_SYSCALL؛ بينما توجد `scx_bpf_dsq_insert_vtime()` في مجموعة enqueue_dispatch، التي قد تستدعيها ops.enqueue() و ops.dispatch() مع أي مهمة KF_RCU -- حيث لا تحتوي المجموعة على تحقق من kf_tasks، ويقوم scx_dsq_insert_preamble() بالتحقق من ملكية المهمة باستخدام scx_task_on_sched() تحديداً لأن @p قد تكون مهمة عشوائية.
يمثل `scx_task_sched(p)` القيمة p->scx.sched، وهي NULL للمهام التي تلي sched_ext_dead() -- والتي تقوم بتصفيرها عبر scx_disable_and_exit_task() عند الخروج -- وللمهام الخاملة (idle tasks)، والتي تتخطى مسارات التفعيل لأنها لا تُجدول أبداً من خلال SCX. كما أنه استدعاء rcu_dereference_protected() يتوقع وجود قفل pi_lock أو قفل rq الخاص بـ @p، ولا يمسك أي من الأغطية بهما. يؤدي تمرير NULL إلى scx_error() للوصول إلى scx_vexit()، والتي تقوم بالوصول إلى sch->exit_info، مما يسبب تعطل النواة (oops).
أحد المحفزات المحددة التي تم اختبارها أثناء تطوير الإصلاح: برنامج BPF_PROG_TYPE_SYSCALL يستدعي غطاء select_cpu_and على مهمة منتهية ولكن لم يتم جمعها بعد (exited-but-not-reaped) بينما كان جدول فرعي متصلاً (يبقى معرف الـ pid قابلاً للعثور عليه طالما أن المهمة الشبحية غير مجمعة؛ تعليمات الخطأ هي مقدمة scx_vexit() "mov r15,[rdi+0x398]" مع RDI=NULL و 0x398 كإزاحة لـ sch->exit_info):
sched_ext: BPF scheduler "kfunc_subsched_null" enabled sched_ext: BPF sub-scheduler "kfunc_subsched_null" enabled sched_ext: Unassociated program run_select_cpu_ (id 76) BUG: kernel NULL pointer dereference, address: 0000000000000398 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP NOPTI
CPU: 7 UID: 0 PID: 8201 Comm: kfunc_test_runn Tainted: G W RIP: 0010:scx_vexit+0x25/0xa0 Code: ... <4c> 8b bf 98 03 00 00 ... CR2: 0000000000000398 Call Trace: <TASK> __scx_exit+0x4f/0x70 scx_bpf_select_cpu_and+0xab/0xb0 bpf_prog_430ed61a7b66e03a_run_select_cpu_and+0x9c/0xe7 ? __x64_sys_bpf+0x2c/0x40 bpf_prog_test_run_syscall+0x130/0x2f0 __sys_bpf+0x930/0x10d0 ? __x64_sys_bpf+0x2c/0x40 __x64_sys_bpf+0x2c/0x40 do_syscall_64+0xbc/0x460 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK>
اقرأ جدول @p تحت حماية RCU بدلاً من ذلك، وهو ما يمكن للأغطية فعله من داخل guard(rcu)(): تسببه في الخطأ عند إمكانية تحديده، وعندما لا يمكن تحديده -- أي أن @p هي مهمة تلي sched_ext_dead() أو مهمة خاملة -- فلا يوجد خطأ واضح للإبلاغ عنه، لذا فقط ارفض الاستدعاء كما كان الحال سابقاً دون التسبب في تعطل أي جدول.
من المخطط إزالة هذه الأغطية المتوافقة (COMPAT wrappers) بشكل نهائي بعد انتهاء فترة التقادم (deprecation grace period)، ولكن حتى ذلك الحين -- وبغض النظر عن الجدول الزمني لإزالتها -- يجب ألا تسبب هذه الأغطية تعطلاً للنواة عند التعامل مع مهمة يتم تسليمها إليها.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.