CVE-2026-68283: tracing: Fix use-after-free freeing trigger private data
Greg Kroah-Hartman <[email protected]>
| Newsgroups | org.kernel.vger.linux-cve-announce |
|---|---|
| Message-ID | <2026081026-CVE-2026-68283-30c9@gregkh> |
From: Greg Kroah-Hartman <[email protected]> Description =========== In the Linux kernel, the following vulnerability has been resolved: tracing: Fix use-after-free freeing trigger private data Commit 61d445af0a7c ("tracing: Add bulk garbage collection of freeing event_trigger_data") moved the kfree() of event_trigger_data to a kthread that runs tracepoint_synchronize_unregister() before freeing. That removed the synchronization the trigger .free callbacks used to get implicitly and inline from trigger_data_free(). event_hist_trigger_free(), event_hist_trigger_named_free() and event_enable_trigger_free() free their satellite data (hist_data, cmd_ops, enable_data) right after trigger_data_free() returns. With the synchronization now deferred to the kthread, a concurrent tracepoint handler can still reach that data through the list_del_rcu()'d trigger, causing a use-after-free. The histogram teardown must stay synchronous: remove_hist_vars() and unregister_field_var_hists() have to detach a synthetic event from the histogram before the trigger-removal write returns, otherwise a following command races in and the synthetic-event removal fails with -EBUSY, as the trigger-synthetic-eprobe.tc selftest catches. Make those callbacks wait with the correct barrier - tracepoint_synchronize_unregister(), matching the free kthread - before freeing. The enable trigger has no such synchronous requirement, and a blocking synchronize there would re-serialize the path that commit deliberately deferred. Give it an optional private_data_free() callback that the free kthread runs after its grace period, and free enable_data from there. The Linux kernel CVE team has assigned CVE-2026-68283 to this issue. Affected and fixed versions =========================== Issue introduced in 6.19 with commit 61d445af0a7c70018111919e47beaaee15653f2f and fixed in 7.1.6 with commit b9c8a1400a3bf633f32820d184f3e05fed0f4af7 Issue introduced in 6.19 with commit 61d445af0a7c70018111919e47beaaee15653f2f and fixed in 7.2-rc5 with commit 79097812153b826fc156a2930ec8a90ed9edf4a2 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-68283 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: kernel/trace/trace.h kernel/trace/trace_events_hist.c kernel/trace/trace_events_trigger.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/b9c8a1400a3bf633f32820d184f3e05fed0f4af7 https://git.kernel.org/stable/c/79097812153b826fc156a2930ec8a90ed9edf4a2