CVE-2026-89746 in Linux
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix use-after-free with same-name named triggers
When two hist triggers on different events are registered with the same name=, the second one reuses the first as named_data. Both are added to tr->hist_vars by save_hist_vars() during event_hist_trigger_parse(), because save_hist_vars() is called before event_trigger_register() while the named reuse is only detected later, in hist_register_trigger().
In the named-data branch hist_register_trigger() then frees the second histogram's hist_data via destroy_hist_data(), but never removes its tr->hist_vars list entry, leaving a dangling pointer and leaking the trace_array reference it holds.
A later hist trigger that references a variable makes find_var_file() walk tr->hist_vars and dereference the freed hist_data. The bug is reproducible from userspace by writing three hist triggers to tracefs:
cd /sys/kernel/tracing echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_switch/trigger echo 'hist:keys=common_pid:x=common_pid:name=mh' > events/sched/sched_process_fork/trigger echo 'hist:keys=common_pid:vals=$x' > events/sched/sched_process_exit/trigger
The third write panics the kernel:
BUG: KASAN: slab-use-after-free in find_var_file.part.0+0x272/0x290 Read of size 8 at addr ffff888001f8a0e0 by task sh/1 CPU: 1 UID: 0 PID: 1 Comm: sh Tainted: G D N Call Trace: find_var_file.part.0 find_event_var parse_atom parse_expr __create_val_field event_hist_trigger_parse trigger_process_regex event_trigger_write vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframe Allocated by task 1: event_hist_trigger_parse Freed by task 1: hist_register_trigger+0x618/0xa30 event_hist_trigger_parse The buggy address belongs to freed 2048-byte region Oops: general protection fault ... RIP: find_var_file.part.0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Fix by removing the hist_data from tr->hist_vars and releasing the trace_array reference in the named-data branch of hist_register_trigger() before freeing the hist_data.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/11/2026
The Linux kernel tracing subsystem contains a critical use-after-free vulnerability within its histogram trigger implementation, specifically affecting the handling of named triggers with identical identifiers across different events. This flaw arises from an inconsistency between how variable references are registered and when duplicate names are detected during the lifecycle of event hist triggers. When users configure tracefs to create histograms using specific keys and values, the kernel parses these configurations through a sequence involving save_hist_vars followed by event_trigger_register. The function save_hist_vars adds all defined variables, including those associated with named data structures, into a global list within the trace_array structure known as tr->hist_vars before the actual trigger registration logic determines if a name conflict exists.
The core technical flaw occurs because the detection of duplicate names happens later in the process flow, specifically inside hist_register_trigger after the variable entries have already been appended to the shared list. When the kernel identifies that a second histogram is attempting to use an existing name from another event, it attempts to reuse the first histogram's named_data structure rather than creating a new one. However, during this conflict resolution phase, the code incorrectly frees the hist_data associated with the second, conflicting trigger via destroy_hist_data without removing its corresponding entry from the tr->hist_vars list. This oversight leaves a dangling pointer in the global variable list while simultaneously leaking the trace_array reference held by that freed structure. Consequently, the kernel's internal state becomes corrupted as it retains references to memory regions that have already been returned to the slab allocator for reuse.
The operational impact of this vulnerability is severe, leading to immediate kernel instability and potential denial of service conditions when triggered under specific circumstances. An attacker or a misconfigured system administrator can reproduce this issue by writing three distinct hist triggers to tracefs files associated with different sched events: first creating a histogram on sched_switch named mh, then attempting the same name on sched_process_fork which triggers the duplicate detection and subsequent improper cleanup, and finally accessing that variable from sched_process_exit. The third write operation causes find_var_file to traverse the tr->hist_vars list and dereference the now-freed hist_data pointer. This results in a slab-use-after-free error detected by Kernel Address Sanitizer (KASAN), manifesting as a general protection fault or kernel panic, effectively crashing the system if it occurs on critical initialization paths such as exitcode handling for init processes.
From a security classification perspective, this vulnerability aligns with CWE-416 Use After Free, where memory is accessed after it has been freed, leading to undefined behavior and potential code execution in more complex scenarios involving heap grooming or specific allocation patterns. In the context of the MITRE ATT&CK framework for Linux systems, this flaw relates to techniques that exploit kernel vulnerabilities for privilege escalation or denial of service, specifically falling under Taint Analysis and exploitation of improper resource management within system services. The vulnerability highlights a critical design gap in how shared resources are managed during dynamic configuration changes in real-time tracing tools.
To mitigate this risk, the Linux kernel maintainers have implemented a fix that ensures proper cleanup procedures are followed when duplicate named triggers are detected. The corrected logic now explicitly removes the hist_data entry from the tr->hist_vars list and releases the associated trace_array reference before invoking destroy_hist_data to free the memory. This adjustment guarantees that no dangling pointers remain in the global variable registry, thereby preventing subsequent lookups from accessing invalid memory addresses. System administrators should ensure their kernels are updated with this patch applied, particularly if they utilize advanced tracing features involving named histograms across multiple events. Regular auditing of tracefs configurations and monitoring for kernel logs related to KASAN or general protection faults can also help in identifying potential exploitation attempts or misconfigurations before they lead to system crashes.