CVE-2026-68283 in Linux
Sumário
de VulDB • 11/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
tracing: Corrige use-after-free ao liberar dados privados de gatilho (trigger)
O commit 61d445af0a7c ("tracing: Add bulk garbage collection of freeing event_trigger_data") moveu o kfree() de event_trigger_data para um kthread que executa tracepoint_synchronize_unregister() antes da liberação. Isso removeu a sincronização que os callbacks .free do gatilho (trigger) obtinham implicitamente e inline através de trigger_data_free().
event_hist_trigger_free(), event_hist_trigger_named_free() e event_enable_trigger_free() liberam seus dados satélite (hist_data, cmd_ops, enable_data) logo após o retorno de trigger_data_free(). Com a sincronização agora adiada para o kthread, um manipulador de tracepoint concorrente ainda pode acessar esses dados através do gatilho removido da lista via list_del_rcu(), causando um use-after-free.
A desmontagem (teardown) do histograma deve permanecer síncrona: remove_hist_vars() e unregister_field_var_hists() devem desconectar um evento sintético do histograma antes que a escrita de remoção do gatilho retorne, caso contrário, um comando subsequente entrará em corrida (race condition) e a remoção do evento sintético falhará com -EBUSY, conforme capturado pelo selftest trigger-synthetic-eprobe.tc. Faça esses callbacks aguardarem usando o barrier correto — tracepoint_synchronize_unregister() — correspondendo ao kthread de liberação, antes da liberação efetiva dos dados.
O gatilho de habilitação (enable trigger) não possui tal requisito síncrono, e uma sincronização bloqueante ali re-serializaria o caminho que o commit deliberadamente adiou. Forneça um callback private_data_free() opcional que o kthread de liberação executa após seu período de graça (grace period), e libere enable_data a partir daí.
If you want to get best quality of vulnerability data, you may have to visit VulDB.