CVE Catalog

CVE-2026-97936

Unknown
Published: Translated: NVD NIST

Summary

A vulnerability exists in the Linux kernel tracing subsystem related to the '.stacktrace' histogram modifier. parse_field() sets HIST_FIELD_FL_STACKTRACE before resolving the field name, and create_hist_field() selects HIST_FIELD_FN_STACK based solely on the field pointer, without verifying that the field actually holds a stacktrace. This leads to unbounded copying and memory corruption (out-of-bounds read/write) during event processing.

Risk Assessment

A local attacker or administrator can trigger kernel memory corruption by creating a hist trigger with the '.stacktrace' modifier on any field, potentially causing a system crash (panic) and possibly kernel code execution. The vulnerability does not require debug options, increasing the risk in production environments.

Recommendation

Update the Linux kernel to a version containing the fix that enforces the '.stacktrace' modifier to be applied only to long[] fields and rejects names that do not resolve to a field. Until patching, restrict access to /sys/kernel/tracing/events to trusted users.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS