CVE-2026-99141 in Linux
Riassunto
di VulDB • 28/10/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
tracing: Correzione del crash in print_graph_function_event()
tracing_set_tracer() assegna i flag del tracer appena selezionato con:
tr->current_trace_flags = t->flags ? : t->tracer->flags;
Se il nuovo tracer non definisce né flag statici né flag predefiniti, come hwlat, irqsoff o wakeup, add_tracer() non dispone di una copia dei flag per istanza e entrambi gli operandi sono NULL, quindi tr->current_trace_flags risulta anch'esso NULL.
Il ring buffer non viene cancellato durante il passaggio da un tracer all'altro: viene resettato all'interno di tracer_init(), dopo che current_trace_flags è già stato assegnato. Se il buffer contiene ancora voci function_graph del tracer precedente, la stampa di una di esse provoca la dereferenziazione di un puntatore NULL. Questo scenario si è verificato durante l'esecuzione di cat trace in un test di stress su ftrace:
BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:print_graph_function_event+0xe/0x20 Call Trace: s_show+0x4d/0x110 seq_read_iter+0x2d4/0x490 seq_read+0x130/0x170 vfs_read+0xb5/0x370 ksys_read+0x6d/0xe0 do_syscall_64+0xbc/0x450
Il buffer snapshot non viene resettato affatto, quindi il problema può essere riprodotto senza condizioni di race:
echo function_graph > /sys/kernel/tracing/current_tracer echo 1 > /sys/kernel/tracing/snapshot echo hwlat > /sys/kernel/tracing/current_tracer cat /sys/kernel/tracing/snapshot
Invece di insegnare a ogni utente di tr->current_trace_flags come gestire questo caso limite, ci si assicura che non sia mai NULL: quando il tracer appena selezionato non ha flag definiti, tracing_set_tracer() utilizza un fallback su no_tracer_flags statico vuoto. run_tracer_selftest può incontrare lo stesso scenario, quindi viene aggiunto anche lì lo stesso meccanismo di fallback. Gli utenti esistenti gestiscono già opts == NULL, quindi questi tracer continuano a comportarsi come in precedenza.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.