---
id: "CVE-2026-99234"
kind: "vulnerability"
aliases: ["CVE-2026-99234"]
title: "Linux kernel: failed tracing command leaves histogram trigger active"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["ftrace", "linux-kernel", "runtime", "self-hosted"]
not_affected_if: ["default-config"]
published_at: "2026-11-02T16:17:48+00:00"
first_seen_at: "2026-11-02T16:24:06+00:00"
updated_at: "2026-11-02T16:26:49+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99234", "first_seen_at": "2026-11-02T16:24:06+00:00"}]
---

# Linux kernel: failed tracing command leaves histogram trigger active

When a histogram trigger command fails partway, the kernel frees its tracking record but leaves the helper histogram trigger registered and still counting events. The sources do not describe a way for an attacker to gain access or run code from this.

_Summary, check and fix written by a model from the sources; labelled as such._

## Timeline

- 2026-11-02T16:24:06+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-99234

## From the sources

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

tracing: Unregister field variable histograms when the command fails

An action that names a field on another event needs that field as a
variable, so create_field_var_hist() registers a second hist trigger on
that event to provide it, and records it in
target_hist_data->field_var_hists[].

If a later part of the same command fails, create_actions() returns an
error and event_hist_trigger_parse() jumps to out_free. The write fails
with -EINVAL and sched_switch gets no trigger, but:

  # echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> \
      events/sched/sched_waking/trigger
  # echo 'my_synth u64 lat; int a; int b' >> synthetic_events
  # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\
      onmatch(sched.sched_waking).my_synth($wakeup_lat,prio,nosuchfld)'\
      >> events/sched/sched_switch/trigger
  # cat events/sched/sched_waking/trigger
  hist:keys=pid:vals=hitcount:ts0=common_timestamp.usecs:sort=hitcount:size=2048:clock=global [active]
  hist:keys=pid:vals=hitcount:synthetic_prio=prio:sort=hitcount:size=2048 [active]

The second histogram is the one created for 'prio'. It is still active and
still counting.

out_free reaches destroy_field_var_hists(), which frees the
field_var_hists[] entries, but never unregister_field_var_hists(), which is
what removes the triggers and runs only from event_hist_trigger_free(). The
entry is freed and the trigger is left with nothing tracking it.

Unregister the field variable histograms in out_free as well, and record
each one as soon as its trigger is registered rather than after the lookup
that follows it, so no exit can leave a registered trigger untracked. The
entry then belongs to field_var_hists[] and is released by
destroy_field_var_hists(), so freeing it on that exit would be a double
free.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_