CVE-2026-97935: tracing: Set the trace clock before registering the histogram trigger

In the Linux kernel, the following vulnerability has been resolved:

tracing: Set the trace clock before registering the histogram trigger

histregistertrigger() puts the trigger on the global namedtriggers list in cmdops->init(), and only then sets the trace clock:

if (data->cmdops->init) { ret = data->cmdops->init(data); if (ret < 0) goto out; }

if (histdata->enabletimestamps) { ret = tracingsetclock(file->tr, histdata->attrs->clock); if (ret) { histerr(tr, HISTERRSETCLOCKFAIL, errpos(clock)); goto out; }

The clock string is not checked anywhere before that call, so a named trigger using commontimestamp with an unknown clock fails after it has already become findable. eventhisttriggerparse() then frees it without taking it off the list, and the next lookup by name reads the freed object:

~# cd /sys/kernel/tracing/events/sched/schedswitch ~# echo 'hist:name=foo:keys=commonpid:ts=commontimestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=commonpid' > trigger

BUG: KASAN: slab-use-after-free in findnamedtrigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 findnamedtrigger+0xac/0xc0 histregistertrigger+0xc1/0x900 eventhisttriggerparse+0x3146/0x6af0 eventtriggerwrite+0xce/0x160 Freed by task 63: kfree+0x154/0x420 triggerkthreadfn+0xfd/0x160

Set the clock before the trigger is registered, so that nothing which can fail runs after it is published, the way commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting namedtriggers list") moved the registration below the rest of the setup.

tracingsetfilterbuffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first.