CVE-2026-89746 in Linux
Sumário
de VulDB • 11/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
tracing: Corrige use-after-free com gatilhos nomeados de mesmo nome
Quando dois triggers hist em eventos diferentes são registrados com o mesmo name=, o segundo reutiliza o primeiro como named_data. Ambos são adicionados à lista tr->hist_vars por save_hist_vars() durante event_hist_trigger_parse(), porque save_hist_vars() é chamado antes de event_trigger_register(), enquanto a reutilização nomeada só é detectada mais tarde em hist_register_trigger().
No branch de dados nomeados, hist_register_trigger() então libera o hist_data do segundo histograma via destroy_hist_data(), mas nunca remove sua entrada na lista tr->hist_vars, deixando um ponteiro dangling e vazando a referência trace_array que ele contém.
Um trigger hist posterior que referencia uma variável faz find_var_file() percorrer tr->hist_vars e dereferenciar o hist_data liberado. O bug é reproduzível do userspace escrevendo três triggers hist no tracefs:
cd /sys/kernel/tracing echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_switch/trigger echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_process_fork/trigger echo 'hist:keys=common_pid:vals=$x' > events/sched/sched_process_exit/trigger
A terceira gravação causa um panic no kernel:
BUG: KASAN: slab-use-after-free in find_var_file.part.0+0x272/0x290 Read of size 8 at addr ffff888001f8a0e0 by task sh/1 CPU: 1 UID: 0 PID: 1 Comm: sh Tainted: G D N Call Trace: find_var_file.part.0 find_event_var parse_atom parse_expr __create_val_field event_hist_trigger_parse trigger_process_regex event_trigger_write vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Allocated by task 1: event_hist_trigger_parse Freed by task 1: hist_register_trigger+0x618/0xa30 event_hist_trigger_parse The buggy address belongs to freed 2048-byte region Oops: general protection fault ... RIP: find_var_file.part.0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Correção removendo o hist_data de tr->hist_vars e liberando a referência trace_array no branch named-data de hist_register_trigger() antes de liberar o hist_data.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.