Description
In the Linux kernel, the following vulnerability has been resolved:

tracing: Fix memory corruption from a "STACKTRACE" histogram key

"cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined
with an offset and a size of zero so that the filter code can match them
by name. parse_field() maps them onto their common_* equivalents for
backward compatibility, but unlike the common_* names it hands the
placeholder back to the caller instead of NULL.

create_hist_field() takes a non-NULL field as a promise that the record
carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc
word is read from offset 0, that is from common_type, and its low 16
bits are followed as an offset into the record. What is found there
becomes the length of an unbounded memcpy. Pick an event whose id is
small enough that the offset stays inside its own record and the length
is a kernel text address:

# cd /sys/kernel/tracing
# echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger
# echo hello > trace_marker

Oops: general protection fault, probably for non-canonical address
RIP: 0010:rb_next+0x23/0x60
</IRQ>
RIP: 0010:memcpy+0xc/0x30
event_hist_trigger+0x2e7/0x12c0
Kernel panic - not syncing: Fatal exception in interrupt

Leave the field NULL, which is what the comment above the branch says
the code does and what common_stacktrace already does. FILTER_CPU and
FILTER_COMM are left alone, their create_hist_field() branches never
look at the field.
Published: 2026-09-25
Score: n/a
EPSS: n/a
KEV: No
Impact: Denial of Service
Action: Immediate Patch
AI Analysis

Impact

A memory corruption vulnerability exists in the Linux kernel tracing subsystem. By crafting a histogram key named "STACKTRACE" and writing a trigger event to the tracing interface, an attacker can cause the kernel to execute an unbounded memcpy that reads from an arbitrary address, leading to a general protection fault and a kernel panic. This results in a denial of service, halting the affected system. The issue arises from improper bounds checking when mapping generic field names to their internal representations, allowing a zero‑size placeholder to be used as a length for a memcpy operation.

Affected Systems

All Linux kernel releases prior to the patch referenced in the included git commits are affected. The vulnerability manifests through the /sys/kernel/tracing interface and requires the ability to write to the 'trace_marker' file or the 'events/ftrace/print/trigger' file, typically necessitating root or elevated privileges.

Risk and Exploitability

The CVSS score is not available in the provided data, but the severity is high as the flaw can crash the kernel. The EPSS score is not reported, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires local access and the ability to write to the tracing debug filesystem, making the attack vector a local privilege escalation or a compromised privileged process. Once exploited, the kernel will panic, causing an immediate denial of service for all users on the machine.

Generated by OpenCVE AI on September 25, 2026 at 18:22 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the latest Linux kernel update that includes the fix for tracing stacktrace memory corruption.
  • Restrict write permissions to /sys/kernel/tracing (e.g., set TRACE_DIR mode 0555 or configure SELinux/AppArmor to block untrusted processes from writing to trace_marker or trigger files).
  • Continuously monitor dmesg and system logs for kernel panic messages related to tracing and confirm that the kernel has been patched.

Generated by OpenCVE AI on September 25, 2026 at 18:22 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

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

Type Values Removed Values Added
Weaknesses 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 a "STACKTRACE" histogram key "cpu", "CPU", "stacktrace" and "STACKTRACE" are generic fields, defined with an offset and a size of zero so that the filter code can match them by name. parse_field() maps them onto their common_* equivalents for backward compatibility, but unlike the common_* names it hands the placeholder back to the caller instead of NULL. create_hist_field() takes a non-NULL field as a promise that the record carries a stacktrace and picks HIST_FIELD_FN_STACK, so the __data_loc word is read from offset 0, that is from common_type, and its low 16 bits are followed as an offset into the record. What is found there becomes the length of an unbounded memcpy. Pick an event whose id is small enough that the offset stays inside its own record and the length is a kernel text address: # cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt Leave the field NULL, which is what the comment above the branch says the code does and what common_stacktrace already does. FILTER_CPU and FILTER_COMM are left alone, their create_hist_field() branches never look at the field.
Title tracing: Fix memory corruption from a "STACKTRACE" histogram key
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-09-25T10:22:49.212Z

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

Link: CVE-2026-97934

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

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

Modified: 2026-09-25T11:17:20.733

Link: CVE-2026-97934

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-25T18:30:17Z

Weaknesses