CVE-2026-68283

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix use-after-free freeing trigger private data<br /> <br /> Commit 61d445af0a7c ("tracing: Add bulk garbage collection of freeing<br /> event_trigger_data") moved the kfree() of event_trigger_data to a kthread<br /> that runs tracepoint_synchronize_unregister() before freeing. That removed<br /> the synchronization the trigger .free callbacks used to get implicitly and<br /> inline from trigger_data_free().<br /> <br /> event_hist_trigger_free(), event_hist_trigger_named_free() and<br /> event_enable_trigger_free() free their satellite data (hist_data, cmd_ops,<br /> enable_data) right after trigger_data_free() returns. With the<br /> synchronization now deferred to the kthread, a concurrent tracepoint<br /> handler can still reach that data through the list_del_rcu()&amp;#39;d trigger,<br /> causing a use-after-free.<br /> <br /> The histogram teardown must stay synchronous: remove_hist_vars() and<br /> unregister_field_var_hists() have to detach a synthetic event from the<br /> histogram before the trigger-removal write returns, otherwise a following<br /> command races in and the synthetic-event removal fails with -EBUSY, as the<br /> trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait<br /> with the correct barrier - tracepoint_synchronize_unregister(), matching<br /> the free kthread - before freeing.<br /> <br /> The enable trigger has no such synchronous requirement, and a blocking<br /> synchronize there would re-serialize the path that commit deliberately<br /> deferred. Give it an optional private_data_free() callback that the free<br /> kthread runs after its grace period, and free enable_data from there.