CVE-2026-99234: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-99234 is a denial-of-service vulnerability in the Linux kernel's tracing subsystem, specifically in the histogram trigger handling logic. When a histogram trigger command with a field variable action fails partway through execution, the field variable histograms registered via create_field_var_hist() are not properly unregistered, leaving orphaned triggers active and consuming kernel resources. The vulnerability affects Linux kernel versions from 4.17 onward, with fixes available in stable branches including 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, 6.18.60, 7.2.14, and 7.3.1. The CVSS category is estimated as Medium (Feedly, GitHub Advisory).

The root cause is improper cleanup in the error path of event_hist_trigger_parse() in the Linux kernel tracing subsystem. When create_actions() returns an error and execution jumps to out_free, the code calls destroy_field_var_hists() — which frees the field_var_hists[] entries — but never calls unregister_field_var_hists(), which is responsible for removing the actual kernel triggers. This results in a use-after-free-adjacent condition where a registered trigger has no tracking structure, and the orphaned histogram continues counting events indefinitely. The fix ensures that field variable histograms are unregistered in the out_free path and that each trigger is recorded immediately upon registration to prevent any exit path from leaving a registered trigger untracked (GitHub Advisory).

A local user with write access to the tracefs interface (typically requiring root or CAP_SYS_ADMIN capability) can trigger failed histogram commands that leave orphaned triggers running, continuously consuming kernel memory and CPU resources. The primary impact is a denial of service through resource exhaustion — the orphaned triggers keep counting kernel events without any mechanism to stop or track them. There is no evidence of confidentiality or integrity impact; the vulnerability is limited to availability (Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). Exploitation requires local access with elevated privileges (CAP_SYS_ADMIN or root), significantly limiting the attack surface. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, and no threat actor attribution has been reported.

1. Gain privileged local access: Obtain a local shell with root or CAP_SYS_ADMIN capability on a vulnerable Linux system (kernel >= 4.17, unpatched).
2. Set up a prerequisite histogram trigger: Write a valid histogram trigger to a tracing event, e.g., echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> /sys/kernel/tracing/events/sched/sched_waking/trigger.
3. Create a synthetic event: Define a synthetic event, e.g., echo 'my_synth u64 lat; int a; int b' >> /sys/kernel/tracing/synthetic_events.
4. Submit a malformed histogram command: Write a histogram command referencing a valid field (e.g., prio) and a nonexistent field (e.g., nosuchfld) to trigger partial registration followed by failure: echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:onmatch(sched.sched_waking).my_synth($wakeup_lat,prio,nosuchfld)' >> /sys/kernel/tracing/events/sched/sched_switch/trigger.
5. Observe orphaned trigger: Verify that the field variable histogram for prio remains active on sched_waking despite the command failing with -EINVAL, by reading /sys/kernel/tracing/events/sched/sched_waking/trigger.
6. Repeat to exhaust resources: Repeat the malformed command to accumulate additional orphaned triggers, progressively consuming kernel memory and CPU (GitHub Advisory).

• File System / tracefs: Unexpected or duplicate histogram triggers visible in /sys/kernel/tracing/events/sched/sched_waking/trigger or similar event trigger files, particularly entries marked [active] that do not correspond to any intentionally configured trigger.
• Logs: Kernel log entries (via dmesg) showing -EINVAL errors from histogram trigger writes alongside continued active trigger counts on the same event.
• Process / Resource: Unexplained increases in kernel CPU usage or memory consumption correlated with tracefs write activity, detectable via top, perf, or kernel memory accounting tools.
• Audit Logs: Audit records of writes to tracefs trigger files (e.g., /sys/kernel/tracing/events/*/trigger) by privileged users, especially repeated failed writes followed by anomalous trigger counts.

Apply the upstream kernel patches available for all affected stable branches: 5.10.273, 5.15.224, 6.1.191, 6.6.161, 6.12.115, 6.18.60, 7.2.14, and 7.3.1. Patch commits are available at the kernel stable repository (e.g., f21351d1c4cd, dba0f4927039, a3d7ffd24097, aae0ccd7326e, 8482ec5b65f6, 431959fc7645, 5afb9317e2ee, d0090baf02dd). As a workaround prior to patching, restrict write access to the tracefs filesystem (typically /sys/kernel/tracing/) to trusted administrators only, and monitor for unexpected active triggers in event trigger files (GitHub Advisory).