CVE-2026-68283 in Linux
Summary
by MITRE • 08/10/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability exists within the Linux kernel's tracing subsystem where a use-after-free condition can occur during the cleanup of trigger private data. The issue stems from a change in commit 61d445af0a7c that introduced bulk garbage collection for event_trigger_data by moving the kfree() operation to a dedicated kthread that executes tracepoint_synchronize_unregister() before freeing memory. This modification inadvertently removed the implicit synchronization that trigger .free callbacks previously relied upon directly from the trigger_data_free() function, creating a race condition between the memory deallocation and concurrent tracepoint handler execution.
The technical flaw manifests when event_hist_trigger_free(), event_hist_trigger_named_free(), and event_enable_trigger_free() functions attempt to free their satellite data structures (hist_data, cmd_ops, enable_data) immediately after trigger_data_free() returns. Since the synchronization has been deferred to a background kthread, concurrent tracepoint handlers can still access the trigger through the list_del_rcu()'d trigger structure, resulting in use-after-free memory corruption. This vulnerability specifically affects the histogram teardown process which must remain synchronous to prevent race conditions with synthetic event removal operations.
The operational impact of this vulnerability could allow an attacker to exploit the use-after-free condition for privilege escalation or system instability. The race condition occurs during the tracing subsystem's cleanup phase when multiple threads access trigger data simultaneously, potentially enabling malicious code to manipulate freed memory locations or cause kernel crashes. The issue affects systems using the Linux kernel's tracing infrastructure where event triggers are configured and subsequently removed, particularly impacting systems with high-frequency tracepoint activity.
The mitigation strategy involves ensuring proper synchronization barriers during the histogram teardown process by requiring remove_hist_vars() and unregister_field_var_hists() to detach synthetic events from histograms before trigger removal completes. This requires these callbacks to wait using the correct barrier tracepoint_synchronize_unregister() that matches the free kthread's synchronization mechanism. For enable triggers, which do not require synchronous cleanup, the solution implements an optional private_data_free() callback that executes within the kthread's grace period after the synchronization has completed, allowing enable_data to be freed safely without re-serializing the path that was deliberately deferred for performance reasons. This approach aligns with CWE-416 vulnerability classification for use-after-free conditions and follows ATT&CK technique T1059.003 for privilege escalation through kernel memory corruption.