CVE-2026-99234 in Linux
Summary
by MITRE • 11/02/2026
In the Linux kernel, the following vulnerability has been resolved:
tracing: Unregister field variable histograms when the command fails
An action that names a field on another event needs that field as a variable, so create_field_var_hist() registers a second hist trigger on that event to provide it, and records it in target_hist_data->field_var_hists[].
If a later part of the same command fails, create_actions() returns an error and event_hist_trigger_parse() jumps to out_free. The write fails with -EINVAL and sched_switch gets no trigger, but:
# echo 'hist:keys=pid:ts0=common_timestamp.usecs' >> \ events/sched/sched_waking/trigger # echo 'my_synth u64 lat; int a; int b' >> synthetic_events # echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).my_synth($wakeup_lat,prio,nosuchfld)'\ >> events/sched/sched_switch/trigger # cat events/sched/sched_waking/trigger hist:keys=pid:vals=hitcount:ts0=common_timestamp.usecs:sort=hitcount:size=2048:clock=global [active]
hist:keys=pid:vals=hitcount:synthetic_prio=prio:sort=hitcount:size=2048 [active]
The second histogram is the one created for 'prio'. It is still active and still counting.
out_free reaches destroy_field_var_hists(), which frees the field_var_hists[] entries, but never unregister_field_var_hists(), which is
what removes the triggers and runs only from event_hist_trigger_free(). The entry is freed and the trigger is left with nothing tracking it.
Unregister the field variable histograms in out_free as well, and record each one as soon as its trigger is registered rather than after the lookup that follows it, so no exit can leave a registered trigger untracked. The entry then belongs to field_var_hists[] and is released by
destroy_field_var_hists(), so freeing it on that exit would be a double free.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The Linux kernel tracing subsystem contains a resource management flaw within the hist trigger parsing logic, specifically affecting synthetic event definitions that rely on variables derived from other events. This vulnerability arises when a command attempts to name a field from one event as a variable for use in another event's histogram action. To facilitate this cross-event data reference, the create_field_var_hist function registers a secondary hist trigger on the source event and records it within the target_hist_data structure under the field_var_hists array. This mechanism allows complex correlation of events by capturing timestamps or other fields from one trace point to be used in calculations for another.
The core technical flaw occurs when an error is encountered during the parsing of actions, specifically within the create_actions function. If a later part of the command fails validation, such as referencing a non-existent field like nosuchfld, the parser returns an error code and jumps to the out_free label to clean up resources. While this path correctly calls destroy_field_var_hists to free the memory structures associated with the variable histograms, it neglects to call unregister_field_var_hists. This omission leaves the secondary hist trigger on the source event active and registered in the kernel's tracing infrastructure, even though the primary command that requested it has failed and been rolled back from the user perspective.
This oversight results in a state where an orphaned histogram remains active and continues to consume system resources by tracking events without any corresponding user-space configuration or ownership. In practical terms, this manifests as residual triggers on events such as sched_switch or sched_waking that persist after the intended command has failed. These lingering traces can lead to unnecessary CPU overhead due to continuous event recording and potential confusion for administrators who observe active triggers in /sys/kernel/debug/tracing/events that do not correspond to any current configuration intent. Furthermore, because the trigger is no longer tracked by the field_var_hists array, it cannot be properly cleaned up during subsequent operations or module unloads, potentially leading to resource leaks over time.
From a security and stability perspective, this issue represents an improper cleanup of system resources following a failed operation, which aligns with CWE-401: Missing Release of Memory after Effective Lifetime. Although the immediate impact is primarily related to performance degradation and state inconsistency rather than direct privilege escalation or data exfiltration, persistent orphaned kernel objects can contribute to memory pressure and trace buffer exhaustion in high-throughput environments. The vulnerability highlights a critical gap in error handling paths where resource registration occurs before validation completes, necessitating that cleanup routines account for all registered entities regardless of the success status of the initiating command.
To mitigate this issue, the fix involves modifying the out_free path to explicitly unregister field variable histograms using unregister_field_var_hists before freeing them. Additionally, the logic is adjusted so that each histogram trigger is recorded in the tracking array immediately upon registration rather than after a subsequent lookup step. This ensures that every registered trigger has a corresponding entry for cleanup and prevents any exit path from leaving an untracked active trigger. By ensuring that destroy_field_var_hists handles both memory deallocation and, via proper sequencing, triggers the necessary unregister calls or by explicitly calling them in the error path, the kernel maintains consistency between user-space configurations and internal tracing state. This correction eliminates the possibility of orphaned traces and ensures robust resource management during command failures.