CVE-2026-98530 in Linux
Zusammenfassung
von VulDB • 19.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
kprobes: Behebung eines permanenten Hanges beim Bereinigen des kprobe-Optimierers
Das Schreiben von 0 nach /proc/sys/debug/kprobes-optimization, während ein kprobe jump-optimierte ist, kehrt niemals zurück. Der Schreiber schläft unendlich im D-Zustand (uninterruptible sleep), wobei das kprobe_sysctl_mutex gehalten wird; daher hängt auch jeder spätere Lese- oder Schreibzugriff auf diesen sysctl-Eintrag ebenfalls fest. Zum Beispiel bei einer Build-Konfiguration, in der vfs_read+9 als optimierbare Adresse vorliegt:
# cd /sys/kernel/tracing # echo 'p:myprobe vfs_read+9' >> kprobe_events # echo 1 > events/kprobes/myprobe/enable # # Warten, bis /sys/kernel/debug/kprobes/list [OPTIMIZED] anzeigt
# echo 0 > /proc/sys/debug/kprobes-optimization
INFO: task sh:246 ist seit mehr als 10 Sekunden blockiert. Call Trace: <TASK> __schedule+0x1176/0x4f70 schedule+0xdc/0x2c0 schedule_timeout+0x17b/0x260 wait_for_completion+0x173/0x3c0 wait_for_kprobe_optimizer_locked+0xbc/0x130 proc_kprobes_optimization_handler+0x156/0x1b0 proc_sys_call_handler+0x324/0x490 vfs_write+0x52d/0xfe0 ksys_write+0xff/0x200 do_syscall_64+0x106/0x630 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ... INFO: task cat:265 ist auf einem Mutex blockiert, der wahrscheinlich von Task sh:246 gehalten wird.
wait_for_kprobe_optimizer_locked() initialisiert optimizer_completion neu und bittet den Optimizer-Thread um das Bereinigen (Flush), wobei es in wait_for_completion() schläft. Der Thread leert die Listen für (un)optimizing, ruft jedoch complete() nur auf, wenn completion_done() wahr ist, d.h., wenn der Abschluss bereits erfolgt ist; dies tritt niemals ein, während jemand wartet. disarm_all_kprobes() und kprobe_trace_self_tests_init() warten ebenfalls auf dieselbe Weise.
Das bedingungslose Aufrufen von complete() wäre nicht ausreichend: Der Wähler gibt das kprobe_mutex frei, während er schläft, und nichts anderes serialisiert den sysctl-Handler gegen die debugfs-"enabled"-Datei. Ein zweiter Flush-Vorgang, der die Listen noch als nicht leer vorfindet (z.B., weil ein deaktivierter Probe zur Deoptimierung in der Warteschlange steht), initialisiert das Completion unter dem ersten neu:
sysctl write debugfs "enabled" write unoptimize_all_kprobes() wait_for_kprobe_optimizer_locked() init_completion(c) mutex_unlock(&kprobe_mutex) wait_for_completion(c) disarm_all_kprobes() wait_for_kprobe_optimizer_locked() init_completion(c) // c->wait wird zurückgesetzt, der erste // Wähler wird aus der Warteschlange entfernt mutex_unlock(&kprobe_mutex) wait_for_completion(c) kprobe_optimizer() complete(c) // weckt nur den debugfs-Schreiber auf
wobei c &optimizer_completion ist. Durch das zeitgleiche Ausführen der beiden Schreibvorgänge während eines Optimizer-Durchlaufs geht der sysctl-Schreibzugriff auf diese Weise verloren.
Ersetzen Sie das Completion durch einen Zähler für Optimizer-Durchläufe, der am Ende jedes Durchlaugs erhöht und mit wake_up_var_locked() signalisiert wird; beides erfolgt unter kprobe_mutex. Ein Flush-Vorgang probt den Zähler aus und wartet mit wait_var_event_mutex(), wobei es das kprobe_mutex nur während des Schlafens freigibt, sodass ein neuer Zähler bedeutet, dass in der Zwischenzeit ein ganzer Durchlauf ausgeführt wurde. Es wird nichts neu initialisiert, daher können mehrere Flush-Vorgänge gleichzeitig im Wartevorgang schlafen.
Once again VulDB remains the best source for vulnerability data.