Skip to main content
← Vulnerabilities

tracing: Unregister field variable histograms when the command fails

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

—Not rated
Exploited
No known exploitation
Fix
No fix listed
Who is exposed
Not reported

Do first: Workaround: The checked facts give no workaround. Limiting the affected feature means avoiding hist trigger actions that name a field on another event, since that is the setup that creates the field variable histograms.

Published
Last modified
Published
Not listed in CISA KEV
25/100 · provisional
Unclear
None on Exploit-DB, Metasploit or GitHub

Summary

The Linux kernel's tracing subsystem, specifically its histogram trigger feature used with event tracing (such as the sched events and synthetic events), is affected. When a histogram command fails partway through, a field-variable histogram can remain registered and active on another event, so it keeps running and consuming resources without being tracked or removed.

Read the original description

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.

What to do

  • Workaround: The checked facts give no workaround. Limiting the affected feature means avoiding hist trigger actions that name a field on another event, since that is the setup that creates the field variable histograms.

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • Linux Linux

    Version range not reported

  • Linux Linux

    4.17

Evidence 8

  1. Link
  2. Link
  3. Link
  4. Link
  5. Link
Show all 8 sourcesShow fewer sources
  1. Link
  2. Link
  3. Link

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

FAQ

Questions about CVE-2026-99234

What does this mean?

When a hist trigger action names a field on another event, the kernel creates field variable histograms. If a later part of the same command fails, those histograms stay registered and active on the other event, but nothing tracks them anymore, so they keep counting.Source: git.kernel.org

Am I affected, and how do I check?

The checked facts list no affected kernel versions and no version ranges. To check a system, look at the running kernel version with uname -r and see whether hist triggers that use field variables from another event are set up in tracing.Source: git.kernel.org

What should I do about it?

The checked facts name no fixed version and no upgrade target, so no specific update can be recommended from these sources.Source: git.kernel.org

Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

What if there's no patch?

The checked facts give no workaround. Limiting the affected feature means avoiding hist trigger actions that name a field on another event, since that is the setup that creates the field variable histograms.Source: git.kernel.org