CVE-2026-99238 in Linux
Summary
by MITRE • 11/02/2026
In the Linux kernel, the following vulnerability has been resolved:
tracing: Hold trace_types_lock when updating modules in persistent instances
trace_module_record() walks ftrace_trace_arrays from the module notifier without trace_types_lock. A concurrent rmdir of an instance removes it from the list and frees it under that lock, so a module load or unload can walk into a freed trace_array.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/03/2026
The identified vulnerability resides within the Linux kernel tracing subsystem, specifically affecting the interaction between module loading events and persistent ftrace instances. The core technical flaw is a race condition caused by improper synchronization of shared data structures during dynamic updates to the system's tracing configuration. When a new kernel module is loaded or unloaded, the kernel triggers a notifier chain that invokes trace_module_record(). This function iterates through the list of active ftrace_trace_arrays to update tracing records associated with the affected modules. However, this iteration occurs without holding the trace_types_lock, which is the primary synchronization mechanism intended to protect these data structures from concurrent modification.
The operational impact stems from a classic use-after-free scenario. Concurrently, an administrator or automated process may execute a remove directory operation on a persistent tracing instance. This action triggers the removal of that instance's trace_array structure from the global list and subsequently frees its memory allocation while holding the trace_types_lock to ensure atomicity during the structural change. Because trace_module_record() does not acquire this same lock before traversing the list, it may proceed with iteration after a concurrent rmdir operation has already freed the target trace_array object. Consequently, the module notifier logic attempts to access or modify memory that is no longer validly allocated, leading to undefined behavior such as kernel panics, data corruption, or potential privilege escalation if an attacker can control the contents of the freed memory region through heap spraying techniques.
This vulnerability aligns with CWE-416, Use After Free, where a program continues to use a pointer after it has been freed. In terms of MITRE ATT&CK mapping, this represents a mechanism for gaining execution or stability disruption via kernel-level race conditions, often categorized under Defense Evasion or Impact categories depending on the exploitability vector. The lack of proper locking during list traversal violates fundamental concurrency safety principles required in multi-threaded kernel environments where hardware interrupts and user-space requests can trigger conflicting operations simultaneously.
To mitigate this risk, the resolution involves modifying trace_module_record() to acquire the trace_types_lock before walking the ftrace_trace_arrays list. This ensures that any concurrent removal or modification of instances is serialized with respect to module updates, preventing access to freed memory structures. Additionally, developers should consider implementing reference counting for trace_array objects during traversal phases to further safeguard against premature deallocation even if lock contention occurs. System administrators relying on persistent tracing instances should ensure their kernel versions are updated to include this patch, and security auditors should review similar notifier chains in the kernel that access shared lists without adequate synchronization primitives to prevent analogous race conditions elsewhere in the codebase.