CVE-2026-97932 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
tracing: Don't dereference trace_event_file in deferred trigger free
The enable_event trigger defers trace_event_put_ref() to the trigger free kthread, but the trace_event_file can already be freed when the instance is removed.
Keep the trace_event_call directly in enable_trigger_data so the deferred free does not access the freed trace_event_file.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel tracing subsystem contains a race condition vulnerability related to the lifecycle management of trace event files and their associated triggers, specifically within the context of deferred cleanup operations. This issue arises from an improper handling of reference counting and memory deallocation when instances are removed while pending trigger free operations remain in progress. The core flaw lies in the mechanism used by enable_event triggers to manage resource release. When a trigger is disabled or removed, the system often defers the actual freeing of associated resources to avoid holding locks during potentially long-running cleanup processes. In this specific case, the kernel schedules trace_event_put_ref() to be executed later via a dedicated kthread responsible for deferred triggering actions. However, this asynchronous approach creates a window where the underlying data structures may no longer exist at the time the deferred task executes.
The technical vulnerability manifests when an instance is removed from the tracing subsystem while there are still pending trigger free operations queued in the kernel thread pool. The original implementation relied on accessing trace_event_file pointers that were stored within the enable_trigger_data structure to perform reference counting decrements and subsequent memory releases. Because the removal of a tracing instance can immediately deallocate or invalidate these trace_event_file structures, any attempt by the deferred kthread to dereference them results in use-after-free behavior. This is a classic concurrency bug where asynchronous cleanup tasks do not account for the premature destruction of their target objects due to external state changes such as module unloading or subsystem teardown. The race condition allows for memory corruption, kernel panics, or potential privilege escalation if an attacker can trigger this sequence through crafted tracing configurations.
From a security and standards perspective, this vulnerability aligns with CWE-416, which describes Use After Free vulnerabilities where program execution continues after a pointer is used that points to freed memory. The operational impact of such a flaw in the kernel space is severe, as it compromises system stability and integrity. A local attacker with sufficient privileges to manipulate tracing instances could potentially crash the entire operating system by triggering the race condition repeatedly or under specific timing conditions. Furthermore, depending on how the corrupted memory is interpreted during subsequent operations, there may be opportunities for arbitrary code execution, although the primary immediate risk remains denial of service through kernel oops or panic. The vulnerability highlights the complexity of managing asynchronous tasks in a highly concurrent environment like the Linux kernel, where reference counting must be meticulously synchronized with object lifecycles to prevent dangling pointer access.
The resolution involves restructuring how enable_trigger_data stores references to trace events. Instead of relying on indirect pointers to trace_event_file structures that might become invalid during deferred execution, the fix ensures that the trace_event_call is kept directly within the enable_trigger_data structure. This architectural change guarantees that as long as the trigger data exists and its free operation is pending, the associated event call information remains valid and accessible. By embedding the necessary context directly into the persistent data structure rather than referencing external objects with independent lifecycles, the kernel eliminates the race condition window. This approach simplifies memory management logic by tying the lifetime of the referenced data more tightly to the trigger itself, ensuring that deferred cleanup tasks always operate on stable, valid memory addresses regardless of instance removal events.
Mitigation strategies for organizations running affected versions of the Linux kernel involve applying vendor-provided security patches as soon as they become available. For systems where immediate patching is not feasible due to operational constraints, administrators should review and restrict access to tracing capabilities such as ftrace and perf_event if these features are not strictly required by critical applications. Limiting user privileges for tools that interact with the kernel tracer can reduce the attack surface, preventing unauthorized users from creating or removing instances in a manner that could trigger the race condition. Additionally, monitoring system logs for unusual oops messages or trace subsystem errors may help detect exploitation attempts early. Long-term architectural improvements should focus on adopting more robust reference counting mechanisms and ensuring that all asynchronous cleanup routines verify object validity before dereferencing pointers, thereby preventing similar use-after-free scenarios in other kernel components.