UBUNTU-CVE-2026-99234: Double Free
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the command-failure cleanup path (`out_free`), call `unregister_field_var_hists()` before destroying `field_var_hists[]`, and record each field-variable histogram immediately when its trigger is registered so every registered trigger remains tracked and is unregistered on failure.
Event History
Frequently Asked Questions
What conditions are required to trigger this issue?
An attacker or local user needs the ability to configure kernel tracing histogram triggers and synthetic events through the tracing interface. The failure occurs when a histogram command creates a field-variable histogram for a field on another event, then fails later in the same command, such as by referencing an invalid field.
What is the observable impact of a failed trigger command?
The command returns -EINVAL and does not install the intended trigger on the target event. However, a field-variable histogram created earlier in parsing can remain active and continue counting on the referenced event.
How can an administrator identify a leftover histogram?
Inspect the trigger configuration for the event referenced by the failed command. A residual histogram may appear as an active trigger even though the command that created the intended trigger failed.
Which Ubuntu kernel packages are listed as affected?
The listed packages are ubuntu/linux-fips, ubuntu/linux, ubuntu/linux-aws, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-oracle, ubuntu/linux-aws-fips, and ubuntu/linux-azure-fips.