UBUNTU-CVE-2026-97918: Use After Free

In the Linux kernel, the following vulnerability has been resolved: tracing: Undo the registration when enabling the histogram trigger fails Commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting namedtriggers list") described how a trigger that is registered but not on file->triggers ends up freed while still on the global namedtriggers list, and moved the registration down so that histtriggerenable() follows it immediately. One path still gets there. histtriggerenable() adds the trigger and takes it straight back out when the event cannot be enabled: listaddtailrcu(&data->list, &file->triggers); updatecondflag(file); if (traceeventtriggerenabledisable(file, 1) < 0) { listdelrcu(&data->list); updatecondflag(file); ret--; } so the list walk in histunregistertrigger() matches nothing, test stays NULL, and the ->free() that would call delnamedtrigger() is skipped. outunreg falls through to outfree, which frees the trigger anyway: BUG: KASAN: slab-use-after-free in findnamedtrigger+0xac/0xc0 Read of size 8 at addr ffff8880091d3160 by task init/1 findnamedtrigger+0xac/0xc0 histregistertrigger+0xc1/0xa00 eventhisttriggerparse+0x3146/0x6af0 eventtriggerwrite+0xce/0x160 Freed by task 69: kfree+0x154/0x420 triggerkthreadfn+0xfd/0x160 Leave the trigger where histunregistertrigger() can find it and let that undo the registration, which is the only code that knows all of what cmdops->init() took: the named list entry, the histpad reference, the reference on the trigger a named histogram is shared with, and the copied cmdops. It also pairs the failed traceeventtriggerenabledisable(), whose smref and buffered event reference are otherwise left behind. Since ->free() releases triggerdata and, for a trigger that does not share its histogram, histdata with it, outunreg can no longer fall through to outfree. For a trigger that does share, histregistertrigger() has already destroyed the caller's histdata, so the fall-through was reading freed memory there as well. Move the enabletimestamps check in histunregistertrigger() above the ->free() call for the same reason: histdata does not outlive it once the trigger being removed is the one that owns it.