tracing: Save the event file instead of the compatible histogram
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
- Specific setups only
Do first: Check whether your setup matches what the bug needs. A field-variable histogram is created and find_compatible_hist() picks an existing histogram that has no variables of its own. The picked histogram is removed by a user while the target histogram still references it.
- 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? →
- 38/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? →
- Specific setups only
- 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 vulnerability affects the Linux kernel's event tracing histogram code, specifically the handling of histogram field variables. A use-after-free condition can occur when a histogram referenced by a field variable is removed while still in use, which can crash the system or corrupt kernel memory.
Read the original description
In the Linux kernel, the following vulnerability has been resolved: tracing: Save the event file instead of the compatible histogram create_field_var_hist() creates a histogram on the matched event to supply a field variable, and records it on the target so it can be torn down later: hist_data = find_compatible_hist(target_hist_data, file); ... /* Save the compatible histogram information */ var_hist->hist_data = hist_data; hist_data is not the histogram it creates. It is one that was already there, whose keys the new one copies. The saved pointer has a single user, unregister_field_var_hists(), which runs when the target is removed: file = hist_data->field_var_hists[i]->hist_data->event_file; find_compatible_hist() matches on keys alone, so it can pick one with no variables of its own. check_var_refs() then returns false and the user can remove it while the target still points at it: BUG: KASAN: slab-use-after-free in event_hist_trigger_free+0x2b2/0x320 Read of size 8 at addr ffff8880093b90e0 by task init/1 Freed by task 1: kfree+0x154/0x420 event_hist_trigger_free+0x1d5/0x320 event_hist_trigger_parse+0x35f3/0x69e0 trigger_process_regex+0x1a6/0x250 Save the event file instead. It is all the dereference ever wanted, and it does not go away when the user removes a trigger.
What to do
Check whether your setup matches what the bug needs.
A field-variable histogram is created and find_compatible_hist() picks an existing histogram that has no variables of its own. The picked histogram is removed by a user while the target histogram still references it.Workaround: The sources do not describe a workaround. Until a fix is installed, avoid creating field-variable histograms on tracing events and avoid removing histograms that other histograms may still reference, since those are the two conditions the bug needs.
Timeline
- CVE published
- First seen by cve.now
- Posted on X 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-99235
What does this mean?
In the Linux kernel's tracing histogram code, a histogram can be freed while another histogram still points to it, and the code then reads the freed memory (a use-after-free). This happens when a field-variable histogram is created and find_compatible_hist() reuses an existing histogram that has no variables, and that histogram is then removed while the new one still references it.Source: git.kernel.org
Am I affected, and how do I check?
The sources name only the Linux kernel and give no affected version range. To check a system, run uname -r to see the kernel version and look under tracefs for event histogram triggers that use field variables.Source: git.kernel.org
What should I do about it?
The sources do not name a fixed kernel version, so check the Linux kernel advisory or your distribution's security notice for a patched release before upgrading.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 sources do not describe a workaround. Until a fix is installed, avoid creating field-variable histograms on tracing events and avoid removing histograms that other histograms may still reference, since those are the two conditions the bug needs.Source: git.kernel.org