DEBIAN-CVE-2026-99140: Debian/linux vulnerability

Published Oct 28, 2026
·
Updated

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.

Affected Software

3 affected components
debian/linux*
debian/linux*
debian/linux*

Event History

Oct 28, 2026
CVE Published
via OSV·11:17 AM
Data Sourced
via OSV·11:17 AM
DescriptionAffected Software

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203