AZL-112568: CVE-2026-99234 affecting package kernel 6.6.159.1-1
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 createfieldvarhist() registers a second hist trigger on that event to provide it, and records it in targethistdata->fieldvarhists[].
If a later part of the same command fails, createactions() returns an error and eventhisttriggerparse() jumps to outfree. The write fails with -EINVAL and schedswitch gets no trigger, but:
# echo 'hist:keys=pid:ts0=commontimestamp.usecs' >> \ events/sched/schedwaking/trigger # echo 'mysynth u64 lat; int a; int b' >> syntheticevents # echo 'hist:keys=nextpid:wakeuplat=commontimestamp.usecs-$ts0:\ onmatch(sched.schedwaking).mysynth($wakeuplat,prio,nosuchfld)'\ >> events/sched/schedswitch/trigger # cat events/sched/schedwaking/trigger hist:keys=pid:vals=hitcount:ts0=commontimestamp.usecs:sort=hitcount:size=2048:clock=global [active] hist:keys=pid:vals=hitcount:syntheticprio=prio:sort=hitcount:size=2048 [active]
The second histogram is the one created for 'prio'. It is still active and still counting.
outfree reaches destroyfieldvarhists(), which frees the fieldvarhists[] entries, but never unregisterfieldvarhists(), which is what removes the triggers and runs only from eventhisttriggerfree(). The entry is freed and the trigger is left with nothing tracking it.
Unregister the field variable histograms in outfree 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 fieldvarhists[] and is released by destroyfieldvarhists(), so freeing it on that exit would be a double free.
Affected Software
Event History
Frequently Asked Questions
What sequence causes the unintended histogram to remain active?
A tracing histogram action must reference a field on another event, which creates and registers a field-variable histogram on that target event. If a later part of the same command fails, the command returns -EINVAL but the registered field-variable histogram is not removed.
Does a failed tracing-trigger write leave no state behind?
No. In the documented sequence, the sched_switch trigger is not installed after the write fails, but an additional histogram on sched_waking remains active and continues counting.
How can I check for the condition shown in the report?
After a failed trigger command, inspect the trigger file for the referenced event. In the provided example, events/sched/sched_waking/trigger shows a second active histogram containing synthetic_prio=prio, even though the attempted sched_switch trigger failed.