CVE-2026-99233

What it actually does

Incorrect basename-only matching in histogram registration paths allows a non-synthetic trace event to decrement a synthetic event's reference count without a prior increment, producing a use-after-free when an active histogram action retains a pointer to the now-freed synthetic event object.

Why it matters to the business

Local users on affected Linux kernels can trigger kernel memory corruption, leading to crashes, denial of service, or potential privilege escalation; the flaw affects systems that use ftrace histograms and synthetic events, which are common in observability, debugging, and performance tooling.

How an attack unfolds

An attacker with local access creates or triggers a non-synthetic trace event whose basename collides with a synthetic event name, registers a histogram on the colliding event before the synthetic event exists, then removes the histogram after the synthetic event is created, causing an unmatched refcount decrement that frees the synthetic event while a histogram action still holds a reference to it.

How to fix it

Apply the upstream kernel patch that replaces find_synth_event with find_synth_event_call to enforce full event_call identity checks before adjusting synthetic event reference counts; rebuild and deploy the fixed kernel across all affected systems.

How to confirm the fix worked

Confirm the presence of find_synth_event_call in the tracing/histograms implementation and that event_hist_trigger_parse and hist_unreg_all now verify se->call against file->event_call before modifying se->ref; test by registering histograms on both synthetic and identically named non-synthetic events and verifying reference counts remain balanced.

Typical attack path

1. Identify or create a trace event whose basename matches a target synthetic event
2. Register a histogram on the non-synthetic event via event_hist_trigger_parse before the synthetic event is instantiated
3. Create the synthetic event, which receives an initial refcount
4. Remove the histogram on the non-synthetic event, erroneously decrementing the synthetic event refcount to zero
5. Trigger the now-dangling histogram action that still references the freed synthetic event

How to detect it

Review kernel audit logs and ftrace output for repeated registration and unregistration of histograms on events whose names collide with known synthetic events; look for unexpected synthetic event objects being freed while histogram actions remain active.

What your security team should do

• Prioritize patching all Linux kernels that contain the tracing histogram code within the next 30 days given the local attack surface and high CVSS
• Restrict unprivileged access to ftrace and synthetic event creation via existing kernel tracing permission controls until patches are applied
• Monitor for upstream stable and distribution kernel updates that backport the find_synth_event_call verification logic