CVE-2026-64560

ملخص

في نواة لينكس، تم حل الثغرة الأمنية التالية: posix-cpu-timers: منع UAF الناتج عن سباق exec() لغير القائد قام Wongi وJungwoo بفك تشفير والإبلاغ عن سباق متعلق بـ exec() لغير القائد والذي يمكن أن يؤدي إلى UAF: ```c sys_timer_delete() exec() posix_cpu_timer_del() // يلاحظ القائد القديم p = pid_task(pid, pid_type); de_thread(); switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); unhash_task(old_leader); sighand = lock_task_sighand(p) sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL; // يعود بدون إجراء if(!sighand) return 0; free_posix_timer(); ``` هذا "غير ضار" إلا إذا كان المؤقّت المحذوف مُسلّحًا ومُدرجًا في قائمة انتظار p->signal لأنه عند exec() يتم توريث مؤقّت مستهدف بـ TGID. نظرًا لأن sys_timer_delete() حرّر كائن المؤقّت الأساسي posix timer، فإن run_posix_cpu_timers() أو أي عمليات إضافة/حذف متعلقة بـ timerqueue على مؤقّتات أخرى ستصل إلى عقدة timerqueue الخاصة بالكائن المُحرَّر، مما يؤدي إلى UAF. توجد مشكلة مشابهة مقابل posix_cpu_timer_set(). بالنسبة للمؤقّتات posix العادية، فإنها تعيد -ESRCH مؤقتًا إلى مساحة المستخدم، ولكن بالنسبة لحالة الاستخدام في do_cpu_nanosleep() فهي نفس UAF فقط مع اختلاف أن k_itimer مُخصَّص على المكدس. أيضًا، يفشل posix_cpu_timer_rearm() في إعادة تسليح المؤقّت، مما يعني أنه يتوقف عن الانتهاء. أثناء مناقشة الحلول، أشار Frederic إلى مشكلة أخرى: ```c posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand); if (!sh) WARN_ON_ONCE(timer_queued(tmr)); ``` على البنى ضعيفة الترتيب، ليس مضمونًا أن posix_cpu_timer_del() سيلاحظ عمليات التخزين في posix_cpu_timers*_exit() عندما يُلاحظ p->sighand كقيمة NULL، مما يعني أن WARN() قد يكون إيجابيًا كاذبًا. قم بحل هذه المشكلات من خلال: 1) تغيير عملية التخزين في __exit_signal() إلى smp_store_release(). 2) إضافة smp_acquire__after_ctrl_dep() في مسار !sighand الخاص بـ lock_task_sighand(). 3) إنشاء دالة مساعدة للبحث عن المهمة وقفل sighand والتي لا تعود عندما يكون sighand == NULL. بدلاً من ذلك، تعيد محاولة البحث عن المهمة وفقط إذا فشل ذلك تستسلم. 4) استخدام تلك الدالة المساعدة في الدوال الثلاث المتأثرة. #1/#2 يضمنان أن جانب القارئ الذي يلاحظ sighand == NULL يلاحظ أيضًا جميع عمليات التخزين السابقة، أي عمليات التخزين في posix_cpu_timers*_exit() وتلك الموجودة في unhash_task(). #3 يضمن التعامل بأمان مع حالة exec() لغير القائد الموصوفة أعلاه. عندما يعيد البحث عن المهمة القائد القديم، ولكن sighand == NULL فإنه يعيد المحاولة. في حالة exec() لغير القائد، سيلاحظ البحث اللاحق عن المهمة القائد الجديد بسبب #1/#2. في سيناريوهات exit() العادية، يفشل البحث اللاحق. عندما يفشل البحث عن المهمة، تتحقق الدالة أيضًا مما إذا كان المؤقّت لا يزال مُدرجًا في قائمة الانتظار وتصدر تحذيرًا إذا كان الأمر كذلك. لسوء الحظ، لا يوجد ما يمكن فعله حيال ذلك، ولكن نظرًا لأن المهمة لم تعد مرئية، يجب عدم الوصول إلى المؤقّت بعد الآن. يتطلب هذا الفحص أيضًا ترتيب الذاكرة، والذي لا يتم توفيره عندما يفشل البحث الأول. لتحقيق ذلك، يسبق الفحص smp_rmb() الذي يقترن بـ smp_wmb() في write_seqlock() في __exit_signal(). يضمن ذلك أن عمليات التخزين في posix_cpu_timers*_exit() مرئية. يعود تاريخ مشكلة exec() لغير القائد إلى الأيام الأولى لمؤقّتات posix CPU، والتي كانت تخزن مؤشرًا إلى مهمة قائد المجموعة في المؤقّت. من الواضح أن ذلك يفشل عندما يقوم exec() لغير القائد بتبديل القائد. أضاف commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") حلاً مؤقتًا لذلك في عام 2010 والذي استمر ---مقطوع---