Cloudanix VulnDB

CVE-2026-99140

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in Linux kernel tracing can produce error messages when certain performance-monitoring commands are used together.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Race condition in kernel tracing allows hist triggers on filtered events to access ring_buffer committing counter without prior increment when events use per-CPU buffered storage, triggering WARN_ON and recording invalid timestamps via hist_field_timestamp.

Why it matters to the business

Kernel warnings and incorrect event timestamps may appear during tracing or performance analysis on systems using histogram triggers, potentially complicating debugging without affecting core system stability.

How an attack unfolds

An attacker issues commands to attach a filter to sched_switch events followed by a hist trigger keyed on common_timestamp, racing event buffering on one CPU against trigger registration on another so that the committing count remains zero when ring_buffer_event_time_stamp is called.

How to fix it

Apply the upstream fix that invokes tracing_event_time_stamp inside hist_field_timestamp to return the current ring buffer time for buffered events instead of relying on the committing counter.

How to confirm the fix worked

Reproduce the filter-plus-hist-trigger sequence and confirm absence of the ring_buffer_event_time_stamp warning; inspect kernel source for the tracing_event_time_stamp call in hist_field_timestamp.

Typical attack path

  1. Attach filter predicate to sched_switch trace event
  2. Register histogram trigger requesting common_timestamp
  3. Trigger scheduler context switches while the race window exists
  4. Observe WARN_ON in ring_buffer_event_time_stamp and invalid timestamp

How to detect it

Search kernel ring buffer and dmesg for the exact WARN_ON_ONCE(!nest) message originating from ring_buffer_event_time_stamp during hist trigger processing of buffered events.

What your security team should do

  • Watch kernel logs for ring_buffer_event_time_stamp warnings
  • Apply the tracing fix in the next kernel update
  • Limit unprivileged access to trace event trigger configuration until patched

The record

In the Linux kernel, the following vulnerability has been resolved: tracing: Fix hist trigger timestamps for buffered events Syzkaller triggered a WARN_ON_ONCE(!nest) warning: WARNING: kernel/trace/ring_buffer.c:821 at ring_buffer_event_time_stamp Call trace: ring_buffer_event_time_stamp hist_field_timestamp hist_fn_call event_hist_trigger event_triggers_call __event_trigger_test_discard trace_event_buffer_commit do_trace_event_raw_event_sched_switch trace_event_raw_event_sched_switch The warning is probabilistically reproducible and is related to syzkaller executing the following commands: echo 'prev_pid == 999999' > events/sched/sched_switch/filter echo 'hist:keys=common_timestamp' > events/sched/sched_switch/trigger The specific triggering process is as follows: CPU 0 CPU 1 (context switching) (echo 'hist:keys=common_timestamp' > \ events/sched/sched_switch/trigger) do_trace_event_raw_event_##call trace_event_buffer_lock_reserve if (!tr->no_filter_buffering_ref && trace_file->flags & EVENT_FILE_FL_FILTERED) return entry; // return directly event_hist_trigger_parse hist_register_trigger tracing_set_filter_buffering(file->tr, true); tr->no_filter_buffering_ref++; __trace_buffer_lock_reserve rb_start_commit local_inc(&cpu_buffer->committing); // skipped and not executed trace_event_buffer_commit __event_trigger_test_discard event_triggers_call event_hist_trigger hist_fn_call hist_field_timestamp ring_buffer_event_time_stamp nest = local_read(&cpu_buffer->committing); WARN_ON_ONCE(!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, trace_event_buffer_lock_reserve() writes the event into the per-CPU trace_buffered_event temp buffer instead of reserving it in the ring buffer, so cpu_buffer->committing is not incremented. When the event is later processed at commit time by a hist trigger, hist_field_timestamp() -> ring_buffer_event_time_stamp() sees a zero committing count, triggering WARN_ON_ONCE(!nest). tracing_event_time_stamp() was added by commit d8279bfc5e959 ("tracing: Add tracing_event_time_stamp() API") for exactly this case: if the event is the per-CPU trace_buffered_event, it returns the current ring buffer timestamp. But it never gained a caller. Use it in hist_field_timestamp(), 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 packages

Ecosystem Package Introduced Fixed