CVE-2026-99235 in Linux
Summary
by MITRE • 11/02/2026
In the Linux kernel, the following vulnerability has been resolved:
tracing: Save the event file instead of the compatible histogram
create_field_var_hist() creates a histogram on the matched event to supply a field variable, and records it on the target so it can be torn down later:
hist_data = find_compatible_hist(target_hist_data, file); ... /* Save the compatible histogram information */ var_hist->hist_data = hist_data;
hist_data is not the histogram it creates. It is one that was already there, whose keys the new one copies. The saved pointer has a single user, unregister_field_var_hists(), which runs when the target is removed:
file = hist_data->field_var_hists[i]->hist_data->event_file;
find_compatible_hist() matches on keys alone, so it can pick one with no variables of its own. check_var_refs() then returns false and the user can remove it while the target still points at it:
BUG: KASAN: slab-use-after-free in event_hist_trigger_free+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1
Freed by task 1: kfree+0x154/0x420 event_hist_trigger_free+0x1d5/0x320 event_hist_trigger_parse+0x35f3/0x69e0 trigger_process_regex+0x1a6/0x250
Save the event file instead. It is all the dereference ever wanted, and it does not go away when the user removes a trigger.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The Linux kernel tracing subsystem contains a critical use-after-free vulnerability within its histogram handling logic, specifically in the function create_field_var_hist(). This flaw arises from an incorrect reference management strategy where the code attempts to save a pointer to a compatible histogram data structure rather than preserving the event file context. The intended purpose of this operation is to ensure that when a target tracepoint or trigger is removed, any associated field variable histograms can be properly torn down without causing memory corruption or kernel panics. However, the implementation relies on find_compatible_hist(), which matches existing histograms based solely on their keys rather than establishing a robust ownership model for the newly created histogram data.
The core technical flaw lies in the fact that hist_data points to an already existing histogram structure whose keys are being copied by the new histogram instance. This saved pointer is intended to be used exclusively by unregister_field_var_hists() during cleanup operations, where it attempts to access event_file through a chain of dereferences: file = hist_data->field_var_hists[i]->hist_data->event_file. Because find_compatible_hist() can select an existing histogram that has no variables of its own, the subsequent check_var_refs() function may return false, indicating that the reference count is safe to decrement. This allows a user space process or kernel thread to remove the trigger while other parts of the system still hold pointers to the now-freed memory associated with that histogram data structure.
This race condition leads directly to a slab-use-after-free error, as evidenced by Kernel Address Sanitizer (KASAN) reports showing reads from freed addresses within event_hist_trigger_free(). The vulnerability is triggered when an attacker or misconfigured application manipulates tracepoint triggers to create and subsequently remove histograms in rapid succession. By exploiting the window between histogram creation and proper reference counting updates, an adversary can cause the kernel to access memory that has already been returned to the slab allocator for reuse. This results in unpredictable behavior, including potential information disclosure if the freed memory is reused for sensitive data, or denial of service through a kernel panic due to invalid memory access.
From a classification perspective, this vulnerability aligns with CWE-416: Use After Free, as it involves accessing memory after it has been made available for reuse without ensuring that all references have been properly invalidated. In the context of the MITRE ATT&CK framework, this flaw could be leveraged in techniques related to Defense Evasion or Privilege Escalation if an attacker can control the contents written into the reused slab memory. The vulnerability exists within the kernel tracing subsystem, which is a privileged component often exposed through sysfs and debugfs interfaces, making it accessible to local users with appropriate permissions.
The resolution involves modifying create_field_var_hist() to save the event file pointer instead of the compatible histogram data pointer. This approach ensures that the dereference operation in unregister_field_var_hists() accesses stable kernel structures that do not disappear when a user removes a trigger. The event file structure remains valid for the lifetime of the tracepoint, providing a reliable anchor point for cleanup operations without risking access to freed memory. This change eliminates the race condition by decoupling the histogram teardown logic from the volatile state of individual histogram instances.
To mitigate this vulnerability in systems where kernel updates are not immediately available, administrators should restrict access to tracing interfaces such as debugfs and sysfs/kernel/tracing. Limiting write permissions on trigger files prevents unprivileged users from creating or removing histograms that could exploit this race condition. Additionally, enabling KASAN in development kernels can help detect similar memory safety issues early in the software lifecycle. For production environments, ensuring timely application of kernel security patches is essential to close these low-level memory management flaws that pose significant risks to system stability and integrity.