tracing/histograms: Verify event_call identity when updating synth_event refcount
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 histogram is registered on a non-synthetic trace event whose basename matches a synthetic event. The histogram is registered on the non-synthetic event before the synthetic event is created and then removed afterwards.
- 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 tracing subsystem, specifically its histogram and synthetic event handling. A flaw there could let a histogram on an ordinary trace event, matched only by name to a synthetic event, corrupt that synthetic event's reference count, which may lead to it being freed while still in use and potentially cause a kernel crash or memory corruption.
Read the original description
In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Verify event_call identity when updating synth_event refcount In event_hist_trigger_parse() and hist_unreg_all(), the histogram registration and unregistration paths look up find_synth_event() using trace_event_name(file->event_call) and adjust se->ref if a match is found. Because find_synth_event() only compares the event basename, registering or removing a histogram on a non-synthetic trace event whose basename matches a synthetic event erroneously modifies the synthetic event's reference count. If a histogram is registered on the non-synthetic event before the synthetic event is created and removed afterwards, se->ref is decremented without a matching increment, allowing the synthetic event to be freed while an active histogram action still holds a pointer to it. Introduce find_synth_event_call() to verify that &se->call matches file->event_call before adjusting se->ref.
What to do
Check whether your setup matches what the bug needs.
A histogram is registered on a non-synthetic trace event whose basename matches a synthetic event. The histogram is registered on the non-synthetic event before the synthetic event is created and then removed afterwards.Workaround: The available data gives no workaround. Based on the conditions, avoiding histograms registered on non-synthetic events whose basenames match synthetic event names would avoid the triggering setup.
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 6
- Link
- 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-99233
What does this mean?
A histogram registered on a non-synthetic trace event whose basename matches a synthetic event can decrement that synthetic event's reference count without a matching increment. The synthetic event can then be freed while an active histogram action still holds a pointer to it.Source: git.kernel.org
Am I affected, and how do I check?
The available data lists Linux with no version ranges, so the affected kernel versions cannot be determined from it. The bug needs a histogram registered on a non-synthetic event with a matching basename, set up before the synthetic event is created and removed afterward.Source: git.kernel.org
What should I do about it?
The available data names no fixed version, so no upgrade target can be given from it.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 available data gives no workaround. Based on the conditions, avoiding histograms registered on non-synthetic events whose basenames match synthetic event names would avoid the triggering setup.Source: git.kernel.org