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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.