CVE-2026-64560
posix-cpu-timers: منع UAF الناتج عن سباق exec() لغير القائد
- تم النشر
- 29/07/2026
- محدث
- 16/10/2026
- تخصيص CNA
- Linux
- الأدلة المرصودة
- 10/08/2026
CVSS الأساسي
nvd · CVSS 3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hمنخفض · الثلاثين يومًا القادمة
- المئوية
- 50.2%
- تاريخ الموديل
- 15/10/2026
EPSS هو تقدير إحصائي، وليس يقينًا أو مقياسًا للتأثير. ادمجها مع CVSS وحالة KEV والتعرض وبيئتك.
ملخص
في نواة لينكس، تم حل الثغرة الأمنية التالية: 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 والذي استمر ---مقطوع---
المصادر
تحليل لثغرة استخدام بعد التحرير (UAF) في نواة لينكس الخاصة بـ CVE-2026-64560 مع كود إثبات المفهوم (PoC) المُحفِّز للسباق، ومراجعة التصحيح، ومصفوفة الإصدارات المتأثرة من LTS/أندرويد، وفحص ذاتي للأجهزة المحدّثة.
- K80Pro-miro-CVE-2026-64560استغلال
تكييف CVE-2026-64560 المرتبط بالجهاز لـ RedMi K80pro miro OS 3.0.304.0
- op13-cve-2026-64560استغلال
استغلال ثغرة أمنية في نواة أندرويد خاصة بجهاز OnePlus 13 للإصدار CVE-2026-64560، يوفر صلاحيات root مؤقتة عبر ADB shell مع حمولات موثّقة وأدوات نقل.
- cve-2026-64560-a16استغلال
مجموعة أدوات CVE-2026-64560: سلسلة أدوات Go أحادية الملف التنفيذي + منفذ هدف realme RMX5010 (A16، SM8750)
- opace6-cve-2026-64560استغلال
أداة الروت المؤقت لجهاز OnePlus Ace 6 (CVE-2026-64560) - منفذ مُتحقق منه على الجهاز مع عنوان bootidParent المصحح
- xiaomi15-dada-cve-2026-64560استغلال
جهاز مرتبط بتكييف CVE-2026-64560 لجهاز Xiaomi 15 بنظام dada OS4.0.0.8
- opace6-cve-2026-64560استغلال
أداة root مؤقتة لجهاز OnePlus Ace 6 تستغل ثغرة use-after-free في مؤقت POSIX CPU بنواة Linux CVE-2026-64560 للحصول على صلاحيات root حتى إعادة التشغيل، دون تعديل أقسام النظام.
الاستخدام المسؤول
استخدم معلومات الثغرات الأمنية فقط على الأنظمة التي تمتلكها أو المرخص لها باختبارها. يرتبط Kitploit ببيانات تعريف البحث العامة ولا يخزن أكواد الاستغلال أو الحمولات الضارة.