CVE-2026-97936 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix memory corruption from the histogram stacktrace modifier
parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array:
n_entries = *stack; memcpy(entries, ++stack, n_entries * sizeof(unsigned long));
Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do:
# cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true)
BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690
The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes.
Documentation/trace/histogram.rst already states the rule, "must be a long[] type", so enforce it once the name has been resolved. Names which
resolve to no field at all, "hitcount.stacktrace" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel tracing subsystem contains a critical memory corruption vulnerability within its histogram processing logic, specifically involving the stack trace modifier. This flaw arises from an improper sequence of operations during field parsing and validation. When a user configures a histogram trigger with a stack trace modifier, such as hist:keys=parent_pid.stacktrace, the parse_field function initially sets the HIST_FIELD_FL_STACKTRACE flag based solely on the presence of the .stacktrace suffix in the input string. Crucially, this flag is set before the system verifies whether the specified field name actually resolves to a valid kernel data structure that supports stack traces. This premature assignment allows malformed or non-existent fields to proceed through subsequent processing stages without adequate validation checks for their actual type and memory layout compatibility with stack trace operations.
The core technical flaw occurs in the create_hist_field function, which relies on the HIST_FIELD_FL_STACKTRACE flag to determine how to interpret data from kernel ring buffer records. Upon detecting this flag, the code assumes it is safe to read a __data_loc word from the event record and interprets its lower sixteen bits as an offset into that same record. This assumption is dangerous because it does not verify that the underlying field actually contains stack trace data in the expected format. Consequently, if a user specifies a field that resolves to no valid stack trace source or points to incompatible memory structures, such as common pseudo-fields like hitcount which do not hold stack traces, the kernel proceeds with unsafe memory access patterns. The event_hist_trigger function then takes the first word at this calculated offset and treats it as an entry count for copying operations.
This misinterpretation of data leads directly to a severe out-of-bounds write vulnerability. The code executes a memcpy operation that copies n_entries longs into a fixed-size array of thirty-one entries, where n_entries is derived from whatever arbitrary value resides at the calculated memory offset in the event record. Since neither the source nor destination bounds are properly validated against this untrusted count, an attacker can trigger massive buffer overflows by manipulating kernel ring buffer contents or exploiting specific timing conditions to influence data layout. The resulting corruption manifests as a null pointer dereference and general protection faults within critical kernel subsystems such as red-black tree insertion routines used for timer management, effectively allowing local privilege escalation or denial of service through system instability.
From an industry standards perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input and CWE-787 Out-of-bounds Write, reflecting the fundamental failure to validate input lengths before performing memory operations. In terms of attack vectors, it relates to ATT&CK technique T1059 Command and Scripting Interpreter via kernel module injection or trigger configuration abuse, where an unprivileged user can leverage tracing interfaces to execute arbitrary code with kernel privileges by corrupting critical data structures like timer queues and RB trees used for scheduling and interrupt handling. The lack of debug options required to reproduce the issue highlights its severity, as even standard KASAN reports confirm massive out-of-bounds reads indicative of heap or stack corruption that could be exploited in production environments without specialized debugging tools enabled.
To mitigate this vulnerability, it is essential to enforce strict type checking after field name resolution rather than relying on suffix-based heuristics alone. The kernel must verify that the resolved field actually holds a long array type compatible with stack trace extraction before setting flags or proceeding with data interpretation. Additionally, developers should implement bounds checking for all memcpy operations involving dynamically determined entry counts derived from ring buffer records. Users and administrators should restrict access to tracing interfaces such as /sys/kernel/tracing/events/ to trusted users only, applying principle of least privilege to prevent unauthorized configuration of histogram triggers that could exploit these parsing flaws. Regular updates to the Linux kernel are necessary to apply patches that correct this logic error in parse_field and create_hist functions, ensuring that invalid field references like hitcount.stacktrace or non-existent fields are rejected early in the processing pipeline before they can cause memory corruption.