CVE-2026-99235

What it actually does

Use-after-free in Linux kernel tracing when create_field_var_hist saves a pointer to a compatible histogram's hist_data instead of the event file; the referenced hist_data can be freed by event_hist_trigger_free while unregister_field_var_hists still dereferences it via event_file, causing slab-use-after-free.

Why it matters to the business

Local attackers on affected Linux systems can trigger kernel crashes or achieve arbitrary code execution, leading to full system compromise, data loss, or service disruption on any host using dynamic event tracing and histograms.

How an attack unfolds

An attacker with local access crafts a sequence of histogram trigger creations and removals that causes find_compatible_hist to return a histogram lacking its own variables; when the user later removes that trigger, the still-referenced hist_data is freed, and subsequent access in event_hist_trigger_free or unregister_field_var_hists reads freed memory.

How to fix it

Apply the upstream patch that changes the saved pointer from hist_data to the event_file so the reference remains valid after the original histogram is removed; rebuild and boot the fixed kernel on all affected systems.

How to confirm the fix worked

Confirm the kernel source contains the corrected create_field_var_hist logic that stores event_file rather than hist_data, then verify the running kernel was built from that source tree and test that repeated histogram create/remove sequences no longer produce KASAN reports.

Typical attack path

1. Obtain local shell on target Linux system
2. Load or enable tracing subsystem with event histograms
3. Create multiple compatible histograms sharing the same keys via trigger commands
4. Remove the source histogram while the dependent field-var histogram still holds a dangling reference
5. Trigger event_hist_trigger_free or unregister_field_var_hists to dereference freed memory

How to detect it

Inspect kernel logs for KASAN slab-use-after-free reports mentioning event_hist_trigger_free or unregister_field_var_hists; correlate with audit logs showing tracefs writes that create or delete histogram triggers immediately preceding the crash.

What your security team should do

• Prioritize patching all systems that expose tracing interfaces to untrusted local users within the next 48 hours
• Restrict unprivileged access to tracefs and event triggers until kernels are updated
• Monitor for any new exploit code targeting this tracing UAF once public PoCs appear
• Audit custom tracing scripts or tools that dynamically register and unregister histograms