CVE-2026-99140: tracing: Fix hist trigger timestamps for buffered events
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix hist trigger timestamps for buffered events
Syzkaller triggered a WARNONONCE(!nest) warning:
WARNING: kernel/trace/ringbuffer.c:821 at ringbuffereventtimestamp Call trace: ringbuffereventtimestamp histfieldtimestamp histfncall eventhisttrigger eventtriggerscall eventtriggertestdiscard traceeventbuffercommit dotraceeventraweventschedswitch traceeventraweventschedswitch
The warning is probabilistically reproducible and is related to syzkaller executing the following commands:
echo 'prevpid == 999999' > events/sched/schedswitch/filter echo 'hist:keys=commontimestamp' > events/sched/schedswitch/trigger
The specific triggering process is as follows:
CPU 0 CPU 1 (context switching) (echo 'hist:keys=commontimestamp' > \ events/sched/schedswitch/trigger) dotraceeventrawevent##call traceeventbufferlockreserve if (!tr->nofilterbufferingref && tracefile->flags & EVENTFILEFLFILTERED) return entry; // return directly eventhisttriggerparse histregistertrigger tracingsetfilterbuffering(file->tr, true); tr->nofilterbufferingref++; tracebufferlockreserve rbstartcommit localinc(&cpubuffer->committing); // skipped and not executed traceeventbuffercommit eventtriggertestdiscard eventtriggerscall eventhisttrigger histfncall histfieldtimestamp ringbuffereventtimestamp nest = localread(&cpubuffer->committing); WARNONONCE(!nest) // trigger warning
The root cause is that when an event file has a filter attached and the hist trigger has not yet been attached, traceeventbufferlockreserve() writes the event into the per-CPU tracebufferedevent temp buffer instead of reserving it in the ring buffer, so cpubuffer->committing is not incremented. When the event is later processed at commit time by a hist trigger, histfieldtimestamp() -> ringbuffereventtimestamp() sees a zero committing count, triggering WARNONONCE(!nest).
tracingeventtimestamp() was added by commit d8279bfc5e959 ("tracing: Add tracingeventtimestamp() API") for exactly this case: if the event is the per-CPU tracebufferedevent, it returns the current ring buffer timestamp. But it never gained a caller. Use it in histfieldtimestamp(), so that a hist trigger that races onto a buffered event records the current time, which is only marginally later than when the event was recorded, instead of warning and recording a bogus timestamp.