CVE-2026-64560
posix-cpu-timers: UAF durch Nicht-Leader-exec()-Race verhindern
- Veröffentlicht
- 29.07.2026
- Aktualisiert
- 08.09.2026
- CNA zuweisen
- Linux
- Beweise beobachtet
- 10.08.2026
Primäres CVSS
nvd · CVSS 3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HNiedrig · nächste 30 Tage
- Perzentil
- 35,5 %
- Modelldatum
- 21.09.2026
EPSS ist eine statistische Schätzung, keine Gewissheit oder ein Maß für die Auswirkung. Kombinieren Sie es mit CVSS, KEV-Status, Belichtung und Ihrer Umgebung.
Zusammenfassung
Im Linux-Kernel wurde die folgende Schwachstelle behoben: posix-cpu-timers: UAF verhindern, die durch einen Non-Leader-exec()-Race verursacht wird Wongi und Jungwoo haben einen Non-Leader-exec()-Race entschlüsselt und gemeldet, der zu einer UAF führen kann: sys_timer_delete() exec() posix_cpu_timer_del() // Beobachtet den alten 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; // Gibt ohne Aktion zurück if(!sighand) return 0; free_posix_timer(); Dies ist „harmlos", es sei denn, der gelöschte Timer war aktiviert und in p->signal eingereiht, da bei exec() ein auf die TGID ausgerichteter Timer vererbt wird. Da sys_timer_delete() das zugrunde liegende Posix-Timer-Objekt freigegeben hat, greifen run_posix_cpu_timers() oder alle damit verbundenen Timerqueue-Add/Delete-Operationen auf andere Timer auf den Timerqueue-Knoten des freigegebenen Objekts zu, was zu einer UAF führt. Es gibt ein ähnliches Problem in Bezug auf posix_cpu_timer_set(). Für reguläre Posix-Timer gibt es nur vorübergehend -ESRCH an den Benutzerraum zurück, aber für den Anwendungsfall in do_cpu_nanosleep() handelt es sich um dieselbe UAF, nur dass das k_itimer auf dem Stack allokiert ist. Außerdem schlägt posix_cpu_timer_rearm() beim erneuten Scharfschalten des Timers fehl, was bedeutet, dass er aufhört abzulaufen. Während der Diskussion über Lösungen wies Frederic auf ein weiteres Problem hin: 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)); Auf schwach geordneten Architekturen ist nicht garantiert, dass posix_cpu_timer_del() die Stores in posix_cpu_timers*_exit() beobachtet, wenn p->sighand als NULL beobachtet wird, was bedeutet, dass das WARN() ein Fehlalarm sein kann. Lösen Sie diese Probleme, indem Sie: 1) Den Store in __exit_signal() in smp_store_release() ändern. 2) Ein smp_acquire__after_ctrl_dep() in den !sighand-Pfad von lock_task_sighand() einfügen. 3) Eine Hilfsfunktion zum Nachschlagen der Aufgabe und Sperren von sighand erstellen, die nicht zurückkehrt, wenn sighand == NULL ist. Stattdessen wiederholt sie die Aufgabensuche und gibt nur auf, wenn diese fehlschlägt. 4) Diese Hilfsfunktion in den drei betroffenen Funktionen verwenden. #1/#2 stellt sicher, dass die Leserseite, die sighand == NULL beobachtet, auch alle vorhergehenden Stores beobachtet, d. h. die Stores in posix_cpu_timers*_exit() und die in unhash_task(). #3 stellt sicher, dass die oben beschriebene Non-Leader-exec()-Situation ordnungsgemäß behandelt wird. Wenn die Aufgabensuche den alten Leader zurückgibt, aber sighand == NULL ist, wird sie wiederholt. Im Non-Leader-exec()-Fall beobachtet die anschließende Aufgabensuche den neuen Leader aufgrund von #1/#2. In normalen exit()-Szenarien schlägt die anschließende Suche fehl. Wenn die Aufgabensuche fehlschlägt, prüft die Funktion auch, ob der Timer noch eingereiht ist, und gibt eine Warnung aus, falls dies der Fall ist. Leider kann man dagegen nichts tun, aber da die Aufgabe nicht mehr sichtbar ist, sollte auf den Timer nicht mehr zugegriffen werden. Diese Prüfung erfordert auch eine Speicherordnung, die nicht bereitgestellt wird, wenn die erste Suche fehlschlägt. Um dies zu erreichen, wird der Prüfung ein smp_rmb() vorangestellt, das mit dem smp_wmb() in write_seqlock() in __exit_signal() gepaart ist. Dadurch wird sichergestellt, dass die Stores in posix_cpu_timers*_exit() sichtbar sind. Die Geschichte des Non-Leader-exec()-Problems reicht bis in die frühen Tage der Posix-CPU-Timer zurück, die einen Zeiger auf die Gruppen-Leader-Aufgabe im Timer speicherten. Das schlägt offensichtlich fehl, wenn ein Non-Leader-exec() den Leader wechselt. commit e0a70217107e („posix-cpu-timers: workaround to suppress the problems with mt exec") fügte 2010 eine temporäre Problemumgehung dafür hinzu, die überlebte ---abgeschnitten---
Verantwortungsvoller Umgang
Verwenden Sie Schwachstelleninformationen nur auf Systemen, die Sie besitzen oder zu deren Testen Sie berechtigt sind. Kitploit verlinkt auf öffentliche Forschungsmetadaten und speichert keinen Exploit-Code oder bösartige Payloads.