CVE-2026-64560 — Linux-Kernel-posix-cpu-timers-Nicht-Leader-exec()-Race-UAF

Reproducer / PoC (Trigger-Verifikation): Linux & Android (NDK) Dieses Repository dient ausschließlich der Verifikation des Patch-Status auf eigenen Testgeräten sowie zu Studienzwecken; es enthält keinerlei Privilege-Escalation-/Exploit-Primitive.

1. Schwachstellenübersicht

Betroffene Versionen

Die Schwachstelle wurde in v5.7 (2020-05) eingeführt; der Fix wurde in die jeweiligen Stable-Zweige zurückportiert:

Android-Bezug

Android-GKI-Kernel basieren auf 5.10 / 5.15 / 6.1 / 6.6 / 6.12 LTS und sind sämtlich betroffen. Da der Mainline-Fix-Commit am 2026-07-29 veröffentlicht wurde, haben Android-Geräte mit SPL (Security Patch Level) bis einschließlich 2026-08-01 den Fix praktisch noch nicht übernommen. Auf dem Gerät lässt sich die Kernelversion und das SPL mit adb shell cat /proc/version und getprop ro.build.version.security_patch überprüfen.

2. Technische Details

2.1 Hintergrund: POSIX-CPU-Timer und sighand

POSIX-CPU-Timer (timer_create(CLOCK_PROCESS_CPUTIME_ID, ...) / timer_create(CLOCK_THREAD_CPUTIME_ID, ...)) werden im Kernel von kernel/time/posix-cpu-timers.c verwaltet. Jedes k_itimer merkt sich das Ziel-Task über it.cpu.pid; für Timer-Operationen wird lock_task_sighand(p, &flags) benötigt, um die sighand->siglock des Tasks zu sperren und die Timerqueue zu schützen.

Der Commit 55e8c8eb2c7b aus dem Jahr 2020 ersetzte den im Timer gecachten Task-Zeiger durch eine PID-Referenz (um das durch den Workaround von 2010, e0a70217107e, verursachte Problem zu beheben). Vor jeder Operation wird eine Suche mit pid_task(pid, type) durchgeführt. Diese Änderung hinterließ das Race-Fenster dieser CVE.

2.2 Race-Szenario (Non-Leader-Thread exec)

Wenn execve() von einem Nicht-Leader-Thread ausgelöst wird, überträgt de_thread() → switch_leader() die TGID vom alten auf den neuen Leader. Der alte Leader durchläuft release_task() → __exit_signal(), wobei old_leader->sighand = NULL gesetzt und unhash_task(old_leader) ausgeführt wird.

Gleichzeitig läuft auf einer anderen 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 被释放

Das von posix_cpu_timer_del() ermittelte p ist der alte Leader; da p->sighand == NULL ist, nimmt die Funktion an, dass „das Task gerade beendet wird und der Exit-Pfad das Entfernen aus der Queue übernimmt“, und gibt ohne jede Aktion Erfolg zurück. Anschließend gibt free_posix_timer() das k_itimer frei.

Kernpunkt: Anders als exit() ändert exec() die TGID nicht; armed Timer auf Prozessebene (p->signal->cpu_timers) werden vererbt und bleiben eingereiht. Daher:

• run_posix_cpu_timers() (durchläuft die Timerqueue im Tick) greift auf das timerqueue_node des freigegebenen Objekts zu → UAF-Lesen/-Schreiben;
• Auch Add/Delete-Operationen auf andere Timer durchlaufen diesen R-Baum mit dem verwaisten Knoten → UAF.

Gleichartige Probleme bestehen auch in:

• posix_cpu_timer_set(): Normale Timer geben lediglich vorübergehend -ESRCH zurück; der kernelinterne do_cpu_nanosleep() verwendet jedoch ein auf dem Stack allokiertes k_itimer – dieselbe UAF.
• posix_cpu_timer_rearm(): Das Rearm schlägt still fehl, der Timer läuft nicht mehr ab (funktionaler Bug).

2.3 Sekundäres Problem auf Architekturen mit schwacher Speicherordnung

Frederic Weisbecker weist darauf hin: tsk->sighand = NULL in __exit_signal() ist ein gewöhnlicher Store. Auf Architekturen mit schwacher Speicherordnung wie ARM64 ist nicht garantiert, dass posix_cpu_timer_del() beim Beobachten von sighand == NULL auch die vor posix_cpu_timers*_exit() durchgeführten Entfernungs-Schreibvorgänge sieht, wodurch WARN_ON_ONCE(timer_queued(tmr)) fälschlich ausgelöst werden kann.

2.4 Behebungsansatz

1. In __exit_signal() wird auf smp_store_release(&tsk->sighand, NULL) umgestellt;
2. Der !sighand-Pfad von lock_task_sighand() erhält smp_acquire__after_ctrl_dep();
3. Neuer Helper timer_lock_sighand(): Task nachschlagen + sighand sperren; bei sighand == NULL wird nicht zurückgekehrt, sondern die Suche wiederholt – im Exec-Szenario findet man den neuen Leader, im Exit-Szenario gibt man erst auf, wenn die Suche fehlschlägt;
4. Die drei betroffenen Funktionen (_del / _set / _rearm) verwenden einheitlich diesen Helper.

Das vollständige Diff siehe patches/920f893f735e.patch.

3. PoC-Beschreibung (Trigger-Verifikation, keine Privilege-Escalation)

Unter poc/ wird ein Race-Trigger bereitgestellt: Zwei Threads durchlaufen jeweils eine intensive Schleife

• Thread A (Timer-Thread): wiederholt timer_create(CLOCK_PROCESS_CPUTIME_ID) → arming (sehr kurze anfängliche Verfallszeit) → Busy-Wait bis zum Auslösen → timer_delete();
• Thread B (Exec-Thread): wiederholt fork() → im Kindprozess einen Nicht-Leader-Thread erstellen, der execve() aufruft (Non-Leader-Exec ist eine notwendige Bedingung dieser Schwachstelle); der Elternprozess ruft sofort waitpid() zur Wiederverwertung auf.

Wenn timer_delete() genau mit de_thread()/__exit_signal() um die Wette konkurriert, bleibt in ungepatchten Kernen das bereits freigegebene k_itimer weiterhin im R-Baum von signal->cpu_timers hängen; danach greifen run_posix_cpu_timers() oder andere Timerqueue-Operationen auf den verwaisten Knoten zu. Mit einem KASAN-Kernel lassen sich zuverlässig Meldungen wie BUG: KASAN: use-after-free in run_posix_cpu_timers / timerqueue_del beobachten; ohne KASAN äußert sich das typischerweise als gelegentliche Kernel-Warnung oder Panic.

Hinweis zur Art des Inhalts: Dies ist ein reiner C-Race-Trigger; er enthält keinerlei Exploit-Primitive wie Heap-Spray, Objekt-Platzhalter oder RIP-Kontrolle. Um daraus einen Privilege-Escalation-Exploit zu machen, wäre erheblich zusätzliche Arbeit nötig (Heap-Feng-Shui, Platzhalterobjekte im Slab-Cache von k_itimer, Umgehung von KASLR/CFI usw.) und es hängt stark vom jeweiligen Kernel-Build ab. Dieses Repository enthält diesen Teil bewusst nicht.

Verzeichnis

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

3.1 Kompilieren und Ausführen unter 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-Kreuzkompilierung, adb-Push)

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* 查看

Das Gerät muss folgende Voraussetzungen erfüllen:

1. Die Kernelversion liegt im betroffenen Bereich (5.7 bis vor der oben aufgeführten Fix-Version); Geräte mit SPL ≤ 2026-08-01 sind praktisch alle betroffen;
2. Der Patch wurde nicht eingespielt (nach dem Patch läuft der PoC nur leer und beendet sich);
3. Für eindeutige KASAN-Berichte ist ein KASAN-Kernel erforderlich (ein selbst kompilierter GKI/boot.img genügt); bei Original-Kerneln äußert sich ein erfolgreicher Trigger meist als Watchdog/Panic oder als stiller Schaden.

3.3 Trefferprinzip (warum so aufgebaut)

• CLOCK_PROCESS_CPUTIME_ID-Timer zielen auf die TGID → hängen an signal->cpu_timers und werden nach dem Exec vererbt – das ist die Voraussetzung für die UAF (CLOCK_THREAD_CPUTIME_ID funktioniert nicht);
• Non-Leader-Thread-Exec → switch_leader() bewirkt, dass der von pid_task(TGID) zurückgegebene alte Leader anschließend sighand = NULL hat – das ist die notwendige Bedingung für das Race;
• Hochfrequente timer_create/arm/delete-Operationen parallel zu hochfrequentem fork/exec maximieren die Wahrscheinlichkeit, dass posix_cpu_timer_del() in das Fenster fällt; die Timer-Timeout-Verarbeitung (run_posix_cpu_timers) selbst berührt den verwaisten Knoten ebenfalls, ohne dass eine zusätzliche Auslösung nötig ist.

4. Selbstprüfung: Ist mein Gerät bereits behoben?

# 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

Wenn der PoC mehrere Minuten ohne KASAN/Panic läuft und die Kernelversion ≥ der Fix-Version ist, gilt das Gerät als behoben (der PoC bietet außerdem einen --check-Modus für einen leichten Smoke-Test).

5. Referenzlinks

• CVE-Datensatz: https://www.cve.org/CVERecord?id=CVE-2026-64560
• GitHub Advisory: https://github.com/advisories/GHSA-78ph-mc3q-52vv
• Mainline-Fix-Commit: https://github.com/torvalds/linux/commit/920f893f735e92ba3a1cd9256899a186b161928d
• Problemverursachender Commit (v5.7): https://github.com/torvalds/linux/commit/55e8c8eb2c7b6bf30e99423ccfe7ca032f498f59
• Workaround von 2010: https://github.com/torvalds/linux/commit/e0a70217107e
• SUSE-Tracking (inkl. Bugzilla 1273004/1273007): https://www.suse.com/security/cve/CVE-2026-64560

Haftungsausschluss / Disclaimer

Dieses Repository dient ausschließlich der Sicherheitsforschung und Verteidigungsverifikation. Führen Sie es nur auf Geräten aus, die Ihnen gehören oder für die Sie eine schriftliche Genehmigung haben. Der PoC kann Kernel-Instabilität bis hin zur Panic auslösen; führen Sie ihn nicht auf Produktionsgeräten aus. Die Autoren übernehmen keine Verantwortung für Folgen jedweder missbräuchlichen Verwendung.