tracing: Unregister field variable histograms when the command fails
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- 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.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 25/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 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
- CVE published
- First seen by cve.now
Affected versions
- Linux Linux
Version range not reported
- Linux Linux
4.17
Evidence 8
- Link
- Link
- Link
- Link
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
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