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.
Published: 2026-08-10
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The patch discussion reveals that a use‑after‑free occurs in the Linux kernel’s tracing subsystem because the freeing of event trigger data was moved to a kthread that performs tracepoint synchronisation after the data is queued for deletion. Concurrent tracepoint handlers can therefore access the freed memory through the list_del_rcu()'d trigger, causing undefined behaviour. This flaw matches the typical use‑after‑free vulnerability category (CWE‑416) and could manifest as a kernel crash or, in the worst case, allow an attacker to execute code with kernel privileges if they can trigger the problematic tracepoint. The vulnerability is limited to the parts of the tracing module that free hist_data, cmd_ops, and enable_data immediately after calling trigger_data_free. When the graceful kthread freed the data, a concurrent handler could continue to reference the memory and invoke callbacks that no longer exist, creating a window for exploitation. The CVE description does not provide a CVSS score, EPSS value, or KEV status. Therefore, while the theoretical severity is high, the actual risk depends on an attacker’s ability to exploit kernel‑space faults. A local attacker with the ability to trigger tracepoints or inject malicious tracepoint handlers would face the attack vector, allowing either denial of service via a crash or potential privilege escalation if code execution can be coerced. Based on the provided information, the risk is considered high but unproven, with exploitation contingent on advanced knowledge of the tracing subsystem and kernel internals. Proper patching or mitigation is recommended before any attempt at exploitation.

Affected Systems

Any Linux kernel build that includes the tracing subsystem and predates the patch commit 61d445af0a7c. The flaw affects the handling of event_hist_trigger_free, event_hist_trigger_named_free, and event_enable_trigger_free, so all kernels that expose these triggers via tracepoints before the fix are potentially vulnerable. No exact version list is provided, but any kernel version lacking the commit that defers freeing to a kthread is at risk.

Risk and Exploitability

The CVSS score is not available and the EPSS score is not provided, so the likelihood of exploitation is uncertain. However, the nature of a use‑after‑free in kernel space typically denotes a high‑severity vulnerability (CWE‑416). Exploitation requires the attacker to trigger tracepoint handlers or otherwise interact with the freed data, which is typically feasible only from local code execution or from an attacker who can influence kernel tracepoint activity. The vulnerability is not listed in CISA KEV, and no public exploits have been recorded, but given its kernel context it remains a high‑risk item.

Generated by OpenCVE AI on August 10, 2026 at 17:16 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that includes commit 61d445af0a7c, which moves the freeing of event trigger data to a kthread and adds proper tracepoint synchronization.
  • If an immediate kernel update is not possible, disable or remove tracepoints that rely on the affected trigger mechanisms, such as event_hist and event_enable triggers, to eliminate the path for concurrent access to freed data.
  • Continuously monitor kernel logs and system stability for signs of panic or abnormal tracepoint activity, and apply the patch as soon as it becomes available.

Generated by OpenCVE AI on August 10, 2026 at 17:16 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 10 Aug 2026 17:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 10 Aug 2026 12:30:00 +0000

Type Values Removed Values Added
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.
Title tracing: Fix use-after-free freeing trigger private data
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-10T12:02:15.088Z

Reserved: 2026-07-30T09:28:09.379Z

Link: CVE-2026-68283

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-10T20:15:03Z

Weaknesses