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.
Affected Software
Event History
Frequently Asked Questions
What access is needed to trigger this issue?
An attacker needs the ability to write histogram trigger definitions through the tracing event trigger interface, as demonstrated by writes to the sched_switch trigger file under /sys/kernel/tracing/events/sched/.
What input sequence causes the use-after-free?
A named histogram trigger using common_timestamp and an unknown clock value is first submitted, causing trace-clock setup to fail after the trigger has been added to the global named-trigger list. A later lookup of that trigger name, such as another histogram definition with the same name, can read the freed trigger object.
How can administrators identify a potentially vulnerable condition?
A failed attempt to create a named histogram trigger with an invalid clock may return an Invalid argument write error. Subsequent use of the same trigger name can produce a KASAN slab-use-after-free report in find_named_trigger.
What is the relevant mitigation when patching is not immediately possible?
Prevent untrusted users from writing tracing event trigger definitions, and avoid creating named histogram triggers that use common_timestamp with an unrecognized clock value.