CVE-2026-64560 — Linux Kernel posix-cpu-timers: UAF بسبب سباق exec() من خيط غير قائد

مُعيد الإنتاج / PoC (للتحقق من حدوث الثغرة): Linux وAndroid (NDK) يُستخدم هذا المستودع فقط للتحقق من حالة التصحيح ولأغراض البحث والتعلّم على أجهزة الاختبار الخاصة بك، ولا يحتوي على أي بدائيات تصعيد صلاحيات أو استغلال.

1. نظرة عامة على الثغرة

الإصدارات المتأثرة

أُدخلت الثغرة في v5.7 (2020-05)، ونُقل الإصلاح (backport) إلى فروع stable المختلفة:

الصلة بنظام Android

نواة Android GKI مبنية على 5.10 / 5.15 / 6.1 / 6.6 / 6.12 LTS، وجميعها ضمن النطاق المتأثر. نظرًا لأن التزام الإصلاح الرئيسي (mainline) صدر في 2026-07-29، فإن أجهزة Android التي يكون مستوى التصحيح الأمني (SPL) فيها 2026-08-01 أو قبل ذلك لا تتضمن هذا الإصلاح في الغالب. يمكنك التأكد من إصدار النواة وSPL على الجهاز باستخدام adb shell cat /proc/version وgetprop ro.build.version.security_patch.

2. التفاصيل التقنية

2.1 الخلفية: موقّتات POSIX CPU وsighand

تُدار موقّتات POSIX CPU (timer_create(CLOCK_PROCESS_CPUTIME_ID, ...) / timer_create(CLOCK_THREAD_CPUTIME_ID, ...)) داخل النواة عبر kernel/time/posix-cpu-timers.c. يحتفظ كل k_itimer بالمهمة المستهدفة من خلال it.cpu.pid؛ وعند التعامل مع الموقّت يلزم استدعاء lock_task_sighand(p, &flags) للحصول على sighand->siglock الخاص بتلك المهمة لحماية timerqueue.

الالتزام 55e8c8eb2c7b لعام 2020 استبدل مؤشر task المخزَّن مؤقتًا في الموقّت بـ مرجع pid (لإصلاح مشكلة سبّبها workaround عام 2010 e0a70217107e)، مع إجراء بحث pid_task(pid, type) قبل كل عملية. ترك هذا التغيير نافذة السباق (race window) الخاصة بهذه الثغرة.

2.2 سيناريو السباق (exec من خيط غير قائد)

عندما يتم استدعاء execve() بواسطة خيط غير قائد (non-leader thread)، يؤدي de_thread() → switch_leader() إلى نقل TGID من القائد القديم إلى القائد الجديد، ويمرّ القائد القديم عبر release_task() → __exit_signal()، حيث يتم تعيين old_leader->sighand = NULL واستدعاء unhash_task(old_leader).

في الوقت نفسه، على نواة معالجة (CPU) أخرى، يُنفَّذ sys_timer_delete() → posix_cpu_timer_del():

 sys_timer_delete()                        exec()
   posix_cpu_timer_del()
   // 观察到旧 leader
   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();
   sighand = lock_task_sighand(p)            unhash_task(old_leader);
     sh = lock(p, sighand)                   old_leader->sighand = NULL;
                                               unlock(sighand);
     (p->sighand == NULL)
       unlock(sh)
       return NULL;

   // 直接返回，没有摘链！
   if (!sighand)
      return 0;
   free_posix_timer();   // ← k_itimer 被释放

إن p الذي يعثر عليه posix_cpu_timer_del() هو القائد القديم، وعند هذه النقطة يكون p->sighand == NULL، فتعتبر الدالة أن «المهمة في طور الخروج وأن مسار exit سيتكفل بفكّ الارتباط»، وبالتالي تعود بالنجاح دون أن تفعل أي شيء. بعد ذلك يُحرِّر free_posix_timer() كائن k_itimer.

النقطة الأساسية: يختلف exec() عن exit() — ففي exec() لا يتغير TGID، والموقّتات المفعلة (armed) المرتبطة بمستوى العملية (p->signal->cpu_timers) تُورَّث وتبقى في قائمة الانتظار. وبالتالي:

• run_posix_cpu_timers() (الذي يجتاز timerqueue في كل tick) يصل إلى timerqueue_node لكائن مُحرَّر → قراءة/كتابة UAF؛
• عمليات الإضافة/الحذف على موقّتات أخرى ستمرّ أيضًا عبر شجرة rbtree التي تحتوي على عُقد معلّقة (dangling) → UAF.

مشكلات مماثلة موجودة أيضًا في:

• posix_cpu_timer_set(): بالنسبة إلى الموقّت العادي فإنها تُرجع -ESRCH مؤقتًا فقط؛ لكن do_cpu_nanosleep() داخل النواة تستخدم k_itimer مُخَصَّصًا على المكدس (stack)، وهي نفس مشكلة UAF.
• posix_cpu_timer_rearm(): فشل صامت في إعادة التسليح (rearm)، فلا يعود الموقّت ينقضي (خطأ وظيفي).

2.3 مشكلة ثانوية على البنى ضعيفة الترتيب

أشار Frederic Weisbecker إلى أن tsk->sighand = NULL داخل __exit_signal() هو تخزين عادي (plain store)؛ وعلى البنى ضعيفة الترتيب مثل ARM64، عندما يرصد posix_cpu_timer_del() أن sighand == NULL فإنه ليس مضمونًا أن يرصد أيضًا عمليات الكتابة الخاصة بفكّ الارتباط التي سبقت posix_cpu_timers*_exit()، مما قد يؤدي إلى إنذار خاطئ من WARN_ON_ONCE(timer_queued(tmr)).

2.4 خطة الإصلاح

1. في __exit_signal() يتم التعديل إلى smp_store_release(&tsk->sighand, NULL)؛
2. إضافة smp_acquire__after_ctrl_dep() في مسار !sighand داخل lock_task_sighand()؛
3. إضافة دالة مساعدة جديدة timer_lock_sighand(): تبحث عن المهمة + تقفل sighand، وإذا كان sighand == NULL فإنها لا تعود بل تعيد محاولة البحث — في سيناريو exec ستجد القائد الجديد، ولا تستسلم إلا في سيناريو exit عندما يفشل البحث؛
4. الدوال الثلاث المتأثرة (_del / _set / _rearm) تتحول جميعها إلى استخدام هذه الدالة المساعدة بشكل موحّد.

انظر الـ diff الكامل في patches/920f893f735e.patch.

3. شرح الـ PoC (تحقق من الإثارة، وليس استغلالًا لتصعيد الصلاحيات)

يوفر مجلد poc/ مُحفِّز سباق (race trigger): خيطان يعمل كل منهما في حلقة عالية الكثافة

• الخيط A (خيط الموقّت): يكرر timer_create(CLOCK_PROCESS_CPUTIME_ID) → تسليح (arm) (بزمن انتهاء ابتدائي قصير جدًا) → انتظار مشغول (busy-wait) لحدوث الإثارة → timer_delete()؛
• الخيط B (خيط exec): يكرر fork() → داخل العملية الابنة إنشاء خيط غير قائد، يقوم هذا الخيط باستدعاء execve() (exec من خيط غير قائد شرط ضروري لهذه الثغرة)، وتقوم العملية الأم فورًا باستدعاء waitpid() لاستعادة (reap) العملية.

عندما يتزامن timer_delete() مع de_thread()/__exit_signal() في السباق، يبقى k_itimer المُحرَّر مرتبطًا بشجرة rbtree الخاصة بـ signal->cpu_timers في نواة غير مُصحَّحة، وبعد ذلك تصل run_posix_cpu_timers() أو عمليات timerqueue أخرى إلى العقدة المعلّقة. مع نواة KASAN يمكن ملاحظة تقارير مثل BUG: KASAN: use-after-free in run_posix_cpu_timers / timerqueue_del بشكل موثوق؛ وبدون KASAN تظهر عادةً كتحذيرات نواة متقطعة أو panic.

توضيح الطبيعة: هذا مُحفِّز سباق مكتوب بلغة C خالصة، لا يتضمن أي بدائيات استغلال مثل heap spray أو وضع كائنات بديلة (object placement) أو التحكم في RIP. تحويله إلى exploit لتصعيد الصلاحيات يتطلب قدرًا كبيرًا من العمل الإضافي (هندسة الكومة heap feng shui، كائنات بديلة في slab cache حيث يوجد k_itimer، تجاوز KASLR/CFI، إلخ)، ويرتبط ارتباطًا وثيقًا ببناء النواة المحدد. هذا المستودع لا يتضمن هذا الجزء عمدًا.

بنية الدليل

├── README.md                ← 本文
├── patches/
│   └── 920f893f735e.patch   ← mainline 修复补丁全文
└── poc/
    ├── cve_2026_64560_poc.c ← 触发器源码（Linux/Android 通用）
    ├── Makefile             ← Linux / NDK 交叉编译
    └── Android.mk           ← NDK ndk-build（可选）

3.1 البناء والتشغيل على Linux x86_64

cd poc
make                 # 生成 cve_2026_64560_poc
sudo ./cve_2026_64560_poc -d 60
# 观察 dmesg: sudo dmesg -wH | grep -iE 'kasan|use-after|BUG|WARNING'

3.2 Android (ترجمة متقاطعة عبر NDK، ودفع عبر adb)

cd poc
export ANDROID_NDK_HOME=/path/to/ndk
make android         # 生成 cve_2026_64560_poc_arm64（static, pie）

adb push cve_2026_64560_poc_arm64 /data/local/tmp/cvepoc
adb shell chmod 755 /data/local/tmp/cvepoc
adb shell /data/local/tmp/cvepoc -d 120

# 观察内核日志：
adb shell su 0 dmesg -w | grep -iE 'kasan|use-after|BUG|WARNING|timer'
# 无 root 时也可在触发崩溃后用 adb shell cat /sys/fs/pstore/console-ramoops* 查看

يجب أن يستوفي الجهاز الشروط التالية:

1. إصدار النواة ضمن النطاق المتأثر (من 5.7 إلى ما قبل إصدارات الإصلاح في الجدول أعلاه)؛ الأجهزة التي يكون SPL فيها ≤ 2026-08-01 متأثرة في الغالب؛
2. لم يتم تطبيق هذا التصحيح (بعد التصحيح، سيدور الـ PoC دون فائدة ثم يخرج)؛
3. لرؤية تقارير KASAN واضحة، تحتاج إلى نواة KASAN (يكفي نواة GKI/boot.img مترجمة يدويًا)؛ وعند نجاح الإثارة على النواة الأصلية (stock) تظهر عادةً على هيئة watchdog/panic أو تلف صامت.

3.3 مبدأ الإصابة (لماذا صُمم بهذه الطريقة)

• موقّت CLOCK_PROCESS_CPUTIME_ID يستهدف TGID → يُربط بـ signal->cpu_timers ويُورَّث بعد exec — وهذا هو الشرط المسبق لـ UAF (CLOCK_THREAD_CPUTIME_ID لا يصلح)؛
• exec من خيط غير قائد → يجعل switch_leader() القائد القديم الذي يعيده pid_task(TGID) يصبح sighand = NULL فورًا — وهذا شرط ضروري للسباق؛
• الجمع بين timer_create/arm/delete بتردد عالٍ وfork/exec بتردد عالٍ بالتوازي يزيد إلى أقصى حد من احتمال وقوع posix_cpu_timer_del() داخل النافذة؛ ومعالجة انتهاء صلاحية الموقّت (run_posix_cpu_timers) نفسها تلمس العقدة المعلّقة أيضًا، فلا حاجة إلى مُحفِّز إضافي.

4. الفحص الذاتي: هل جهازي مُصحَّح بالفعل؟

# Android:
adb shell cat /proc/version            # 内核版本是否 >= 上表修复版本
adb shell getprop ro.build.version.security_patch   # SPL 是否 > 2026-08
# Linux:
uname -r
# 或直接检查源码是否包含 timer_lock_sighand:
grep -r timer_lock_sighand /usr/src/linux/kernel/time/posix-cpu-timers.c

إذا شغّلت الـ PoC لبضع دقائق دون أي KASAN/panic وكانت النواة ≥ إصدار الإصلاح، فيُعتبر الجهاز مُصحَّحًا (يتضمن الـ PoC نفسه وضع --check لإجراء اختبار دخان (smoke) خفيف).

5. روابط مرجعية

• سجل CVE: https://www.cve.org/CVERecord?id=CVE-2026-64560
• GitHub Advisory: https://github.com/advisories/GHSA-78ph-mc3q-52vv
• التزام الإصلاح في mainline: https://github.com/torvalds/linux/commit/920f893f735e92ba3a1cd9256899a186b161928d
• الالتزام الذي أدخل المشكلة (v5.7): https://github.com/torvalds/linux/commit/55e8c8eb2c7b6bf30e99423ccfe7ca032f498f59
• workaround لعام 2010: https://github.com/torvalds/linux/commit/e0a70217107e
• تتبع SUSE (يشمل Bugzilla 1273004/1273007): https://www.suse.com/security/cve/CVE-2026-64560

إخلاء مسؤولية / Disclaimer

هذا المستودع موجّه فقط للبحث الأمني والتحقق الدفاعي. شغّله فقط على الأجهزة التي تملكها أو التي حصلت على تفويض كتابي لاستخدامها. قد يؤدي الـ PoC إلى عدم استقرار النواة وحتى panic، لذا لا تشغّله على أجهزة الإنتاج. لا يتحمل المؤلف أي مسؤولية عن العواقب الناتجة عن إساءة الاستخدام.