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.
Published: 2026-09-25
Score: 7.0 High
EPSS: < 1% Very Low
KEV: No
Impact: Kernel memory corruption
Action: Apply patch
AI Analysis

Impact

The flaw arises in the Linux kernel’s tracing histogram subsystem, where an unbounded memory copy is performed during event trigger parsing. parse_field() incorrectly assigns a stacktrace modifier before validating the field name, and create_hist_field() subsequently selects a stacktrace field based solely on pointer value. event_hist_trigger() then copies a number of longs specified by the event data into a fixed 31‑entry array without bounds checking, leading to a buffer over‑read and subsequent memory corruption. This is a buffer overflow vulnerability, CWE‑120, that can cause kernel crashes or loss of state.

Affected Systems

All Linux kernel implementations that expose the tracing histogram feature without the commit series referenced in the supplied kernel tree patches are vulnerable. Distributions and custom kernel builds that have not incorporated the 55caaf2… through e183b84… series of changes will be affected, regardless of kernel version, until the fix is applied.

Risk and Exploitability

The CVSS score of 7.0 indicates high severity, while the EPSS score of <1% reflects a low probability of exploitation. The vulnerability is not listed in the CISA KEV catalog, suggesting no widespread exploitation to date. The likely attack vector is local; an adversary must write to a tracing trigger file such as /sys/kernel/tracing/events/<event>/trigger and supply a .stacktrace modifier. Once activated, the kernel will perform the overflow, potentially destabilizing the system. Given the local requirement and the lack of public exploits, the overall risk remains moderate but non‑negligible, warranting timely patching.

Generated by OpenCVE AI on October 1, 2026 at 08:39 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply the official kernel patch that enforces bounds checking and validates histogram stacktrace fields, effectively addressing the CWE‑120 vulnerability.
  • If patching is delayed, remove or disable any tracing events that trigger histograms using the .stacktrace modifier to eliminate the overflow path.
  • Continuously monitor kernel logs for KASAN or out‑of‑bounds access warnings, and apply subsequent security updates promptly to mitigate any remaining risks.

Generated by OpenCVE AI on October 1, 2026 at 08:39 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sat, 03 Oct 2026 11:15:00 +0000


Thu, 01 Oct 2026 06:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-125

Wed, 30 Sep 2026 00:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}

threat_severity

Moderate


Fri, 25 Sep 2026 18:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-120
CWE-125

Fri, 25 Sep 2026 10:30:00 +0000

Type Values Removed Values Added
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.
Title tracing: Fix memory corruption from the histogram stacktrace modifier
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-19T09:11:02.941Z

Reserved: 2026-09-25T10:18:58.204Z

Link: CVE-2026-97936

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-25T11:17:20.963

Modified: 2026-10-19T10:17:44.623

Link: CVE-2026-97936

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-25T00:00:00Z

Links: CVE-2026-97936 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-01T08:45:03Z

Weaknesses
  • CWE-120

    Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')