CVE-2026-97934

Executive Summary

CVE-2026-97934 is a memory corruption vulnerability in the Linux kernel's tracing subsystem, specifically within the histogram trigger field parsing logic. The flaw arises when an operator supplies STACKTRACE (or stacktrace) as a histogram key: parse_field() returns a placeholder field with offset and size of zero instead of NULL, causing create_hist_field() to select HIST_FIELD_FN_STACK and subsequently perform an unbounded memcpy using an attacker-influenced length read from offset 0 of the trace record. This yields an out-of-bounds write that manifests as a general protection fault, kernel panic, or potentially arbitrary kernel memory corruption.

The vulnerability requires local access to the tracing subsystem, which in standard configurations is restricted to root or members of privileged groups. However, on systems where tracefs permissions are relaxed — or in container environments where the tracing interface is exposed — a lower-privileged local user could trigger kernel memory corruption, leading to denial of service or, in a worst-case scenario, local privilege escalation. No public exploit code, PoC, or Nuclei template currently exists, and the CVE remains unpatched per tracked sources.

Technical Analysis

The tracing subsystem in the Linux kernel exposes tracefs, which is typically mounted at /sys/kernel/tracing. Event histograms are created by writing trigger expressions such as hist:keys=STACKTRACE into an event's trigger file. Generic fields — cpu, CPU, stacktrace, and STACKTRACE — are defined with an offset and size of zero so that filter code can match them by name.

Two functions are central to the flaw:

1. parse_field() — For backward compatibility, this function maps generic field names to their common_* equivalents. However, unlike the common_* names, it returns the placeholder field to the caller rather than NULL.
2. create_hist_field() — This function treats any non-NULL field as a promise that the record carries a stacktrace, and consequently selects the HIST_FIELD_FN_STACK handler.

Because the placeholder field has offset 0, the __data_loc word is read from offset 0 of the record — which is the common_type field. The low 16 bits of this value are then followed as an offset into the record. Whatever value resides at that location is interpreted as the length for an unbounded memcpy. By choosing an event whose ID is small enough to keep the offset within the event's own record, an attacker can cause the length value to be read from a kernel text address, resulting in an out-of-bounds write of attacker-influenced size.

The NVD description provides a reproducible crash sequence:

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

The resulting fault is a general protection fault from a non-canonical address, with the call stack showing memcpy invoked from event_hist_trigger:

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

The fix described in the NVD entry is to leave the field NULL in parse_field() — matching what the code comment above the branch says and what common_stacktrace already does. FILTER_CPU and FILTER_COMM branches are explicitly unaffected because their create_hist_field() branches never dereference the returned field.

Attack surface: The vulnerable code path is reached via event histogram trigger creation, accessible through the tracefs interface. This is a local attack surface — no network vector is described by the CNA.

Root cause class: Out-of-bounds write (CWE-787) caused by improper handling of a sentinel/placeholder value (returning a zero-offset field instead of NULL), leading to a type confusion between a generic filter field and a stacktrace-bearing field.

Exploitation Scenarios

No public PoC is available, and the attack chain below is inferred strictly from the vulnerability class and the mechanism described in the NVD entry.

1. Reconnaissance / target identification An attacker with local access to a target system enumerates whether tracefs is mounted (/sys/kernel/tracing) and whether the current user has write access to any event's trigger file. On kernels where tracefs permissions are relaxed (e.g., world-writable or accessible to a non-root user), the target is viable. The attacker identifies an event with a small enough event ID such that the offset derived from offset 0 of the record stays within that same record.

2. Triggering the flaw The attacker writes a histogram trigger expression using the STACKTRACE (or stacktrace) key to the chosen event's trigger file, for example:

echo 'hist:keys=STACKTRACE' > events/<subsystem>/<event>/trigger

This causes parse_field() to return the zero-offset placeholder instead of NULL, so create_hist_field() selects HIST_FIELD_FN_STACK.

3. Payload / execution method The attacker then causes the event to fire (e.g., by writing to the associated trace marker or otherwise generating the traced event), which drives event_hist_trigger. Because the __data_loc word is read from offset 0 (common_type), its low 16 bits are interpreted as an offset into the record; the value found there is used as the length for an unbounded memcpy. By controlling which event fires, the attacker influences the length value pulled into the copy, causing an attacker-influenced out-of-bounds write.

4. Post-exploitation impact Successful triggering produces kernel memory corruption. The observed outcome in the NVD description is a general protection fault and kernel panic (Fatal exception in interrupt), i.e., a local denial of service. Where the corrupted memory can be shaped further, the same primitive could in principle contribute to privilege escalation; however, the NVD entry describes only the crash. No public evidence of a reliable privilege-escalation exploit exists at this time.

Impact Assessment

The vulnerability is a local, kernel-level memory corruption flaw. Its most reliably demonstrated impact is a kernel panic, resulting in a complete denial of service on the affected host. The memcpy length is attacker-influenced, and the out-of-bounds write targets kernel memory, so the impact extends beyond a simple crash in principle.

Referencing the assessed CVSS vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H):

• Attack Vector (Local): exploitation requires local access to the tracefs interface; there is no described remote vector.
• Attack Complexity (High): successful triggering depends on conditions such as event ID selection and record layout.
• Privileges Required (Low): on default hardened systems, tracefs write access requires elevated privileges; however, on relaxed or containerized configurations, a lower-privileged user may reach the vulnerable interface.
• User Interaction (None): the attacker is the actor writing the trigger.
• Scope (Unchanged): corruption is confined to the kernel.
• Confidentiality / Integrity / Availability (all High): kernel memory corruption can affect all three properties, with availability most immediately impacted (panic).

Affected systems: Linux kernels that support histogram triggers on generic STACKTRACE/stacktrace keys — the feature has been present since histogram triggers were introduced (kernel 4.7 era). Any system exposing tracefs to untrusted or lower-privileged users (including some container and cloud multi-tenant scenarios) is at elevated risk. The CNA provides no explicit affected version list.

Blast radius: Because the flaw is in shared tracing infrastructure rather than a single driver, any relying kernel is potentially affected. The practical blast radius on a hardened host is limited to denial of service and requires privileged interface access; on hosts with relaxed tracefs permissions, the blast radius expands to any local user able to write trigger files. No CISA KEV listing and no measured EPSS score are available; FIRST.org has not yet scored this CVE.

Detection Guidance

Sigma Rule

title: Linux Kernel Tracing Histogram STACKTRACE Key Abuse (CVE-2026-97934)
id: 8f2c1a44-5b6e-4c1a-9d3e-1a2b3c4d5e6f
status: experimental
description: Detects writes of histogram trigger expressions using the generic STACKTRACE
  or stacktrace key against event trigger files, consistent with CVE-2026-97934.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-97934
author: valtersit.com
date: 2026/01/01
logsource:
  product: linux
  category: process_creation
detection:
  selection_tool:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/echo'
  selection_cmdline:
    CommandLine|contains:
      - 'hist:keys=STACKTRACE'
      - 'hist:keys=stacktrace'
  selection_target:
    CommandLine|contains:
      - '/sys/kernel/tracing'
      - '/sys/kernel/debug/tracing'
      - '/trigger'
  condition: selection_tool and selection_cmdline and selection_target
falsepositives:
  - Legitimate kernel developers and tracing engineers testing stacktrace histograms
level: high
tags:
  - attack.privilege_escalation
  - attack.t1068
  - cve.2026.97934

YARA Rule

rule CVE_2026_97934_Tracing_Histogram_Stacktrace
{
    meta:
        description = "Detects scripts or command lines abusing the STACKTRACE histogram key in Linux tracing (CVE-2026-97934)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-97934"
        date = "2026-01-01"
    strings:
        $s1 = "hist:keys=STACKTRACE" ascii wide
        $s2 = "hist:keys=stacktrace" ascii wide
        $p1 = "/sys/kernel/tracing" ascii wide
        $p2 = "/sys/kernel/debug/tracing" ascii wide
        $t1 = "/trigger" ascii wide
        $m1 = "trace_marker" ascii wide
    condition:
        any of ($s1, $s2) and
        any of ($p1, $p2, $t1, $m1)
}

Suricata IDS Rule

Because this is a strictly local kernel vulnerability with no described network vector, a true network signature cannot be written. The rule below is a defensive placeholder that will not fire on this CVE alone; it is included for completeness and should not be relied upon as a detection mechanism.

alert tcp any any -> any any (msg:"CVE-2026-97934 - Linux tracing histogram STACKTRACE key (no network vector - local only)"; flow:to_server,established; content:"hist:keys="; nocase; content:"STACKTRACE"; nocase; reference:cve,2026-97934; classtype:attempted-admin; sid:202697934; rev:1;)

Note: CVE-2026-97934 is a local privilege/DoS condition reachable only through the tracefs interface. Host-based detection (Sigma, Wazuh, Elastic) is the appropriate control; network IDS is effectively blind to this attack.

Elastic Detection

sequence by host.id with maxspan=5s
  [process where process.args : "*hist:keys=STACKTRACE*" or process.args : "*hist:keys=stacktrace*"]
  [process where process.args : "*trace_marker*" or process.args : "*/trigger*"]

Splunk SPL Query

index=linux_logs OR index=sysmon_linux
(process_command_line="*hist:keys=STACKTRACE*" OR process_command_line="*hist:keys=stacktrace*")
(process_command_line="*/sys/kernel/tracing*" OR process_command_line="*/sys/kernel/debug/tracing*" OR process_command_line="*/trigger*")
| stats count min(_time) as first_seen max(_time) as last_seen by host, user, process_command_line
| where count > 0
| table host, user, process_command_line, first_seen, last_seen

Wazuh OSSEC Rule

<group name="linux,cve-2026-97934,tracing,">
  <rule id="100934" level="12">
    <if_sid>530</if_sid>
    <match>hist:keys=STACKTRACE|hist:keys=stacktrace</match>
    <description>CVE-2026-97934: Possible Linux tracing histogram STACKTRACE key abuse (memory corruption trigger)</description>
    <mitre>
      <id>T1068</id>
    </mitre>
    <group>privilege_escalation,attack,</group>
  </rule>

  <rule id="100935" level="12">
    <if_sid>530</if_sid>
    <match>/sys/kernel/tracing|/sys/kernel/debug/tracing</match>
    <regex>trigger</regex>
    <description>CVE-2026-97934: Write to tracing event trigger file detected</description>
    <group>privilege_escalation,attack,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, no workaround, no affected-version enumeration, and no OSV package mappings were provided. The NVD description describes the intended fix (leave the zero-offset placeholder field NULL in parse_field(), consistent with common_stacktrace), but no merged patch reference or release version is available in the supplied data.

1. Immediate mitigations

• Restrict tracefs. Ensure /sys/kernel/tracing (and the legacy /sys/kernel/debug/tracing) is mounted with permissions that prevent unprivileged users from writing to event trigger files. In containerized environments, do not expose the tracing interface to untrusted containers.
• Audit group memberships. Verify that only root (or a tightly controlled privileged group) can access tracing control files.
• Monitor for the indicators in the Detection Guidance section — specifically command lines containing hist:keys=STACKTRACE or hist:keys=stacktrace targeting trigger files.
• Where tracing is not operationally required, consider unmounting tracefs entirely.

2. Patch / upgrade steps

• No patch reference or fixed version is available from tracked sources at this time. Monitor the upstream Linux kernel tracing maintainer tree and stable release notes for a commit titled around "tracing: Fix memory corruption from a STACKTRACE histogram key." Apply the kernel update as soon as a fixed version is published by your distribution vendor.
• Track the NVD entry (link below) and your distribution's security advisory feed for affected-version and fix-version data.

3. Long-term hardening

• Apply the principle of least privilege to all kernel debug and tracing interfaces; treat tracefs and debugfs as privileged surfaces.
• Adopt kernel hardening controls (e.g., CONFIG_ restrictions on debug interfaces, lockdown mode where appropriate) that reduce exposure of tracing facilities.
• Maintain an inventory of kernels in use and a process to rapidly deploy stable-branch kernel updates.
• Integrate the host-based detection rules above into your SOC pipeline so that misuse of tracing histogram keys is alerted on even if a trigger does not immediately crash the kernel.

References

• NVD — CVE-2026-97934: https://nvd.nist.gov/vuln/detail/CVE-2026-97934
• Linux Kernel Tracing documentation (histogram triggers): https://www.kernel.org/doc/html/latest/trace/histogram.html
• Linux Kernel Mailing List — tracing subsystem patches (monitor for "tracing: Fix memory corruption from a STACKTRACE histogram key"): https://lore.kernel.org/linux-trace-kernel/
• Linux kernel stable release announcements: https://www.kernel.org/
• CWE-787 — Out-of-bounds Write: https://cwe.mitre.org/data/definitions/787.html

Threat actor / in-the-wild status: No threat actor campaigns, no exploit-in-the-wild evidence, and no CISA KEV listing are associated with this CVE in the supplied data. No public PoC or Nuclei template exists. Exploitation requires local access to the tracing interface; risk is concentrated in environments where tracefs permissions are relaxed.