CVE-2026-97935 in Linux
Zusammenfassung
von VulDB • 25.09.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
Tracing: Setzen der Trace-Clock vor dem Registrieren des Histogramm-Triggers
hist_register_trigger() fügt den Trigger in cmd_ops->init() zur globalen Liste named_triggers hinzu und setzt erst danach die Trace-Clock:
if (data->cmd_ops->init) {
ret = data->cmd_ops->init(data); if (ret < 0) goto out; }
if (hist_data->enable_timestamps) {
ret = tracing_set_clock(file->tr, hist_data->attrs->clock); if (ret) {
hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); goto out; }
Der Clock-String wird vor diesem Aufruf nirgendwo überprüft. Daher schlägt ein benannter Trigger mit common_timestamp und einer unbekannten Clock fehl, nachdem er bereits auffindbar ist. event_hist_trigger_parse() gibt das Objekt dann frei, ohne es von der Liste zu entfernen, und die nächste Suche nach dem Namen liest aus dem freigegebenen Objekt:
~# cd /sys/kernel/tracing/events/sched/sched_switch ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=common_pid' > trigger
BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0x900 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 63: kfree+0x154/0x420 trigger_kthread_fn+0xfd/0x160
Setzen Sie die Clock vor der Registrierung des Triggers, damit nichts, was fehlschlagen kann, nach seiner Veröffentlichung ausgeführt wird. Dies entspricht dem Vorgehen von Commit 6f86bdeab633 („tracing: Fix bad hist from corrupting named_triggers list“), bei dem die Registrierung unter den Rest der Einrichtung verschoben wurde.
tracing_set_filter_buffering() ist referenzgezählt, daher muss im Fehlerpfad des init-Aufrufs zuerst die Referenz freigegeben werden, die durch den Clock-Block nun beansprucht wird.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.