CVE-2026-97936

Status: UPDATED  |  Advisory ID: CVE-2026-97936

Key Details

Affected Products, Subsystems & Sectors

What to Know

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. (NVD)

What to Do

Monitor Linux's web page for any future patch releases.

References