GHSA-JPCJ-Q7F6-FXVJ
Vulnerability from github – Published: 2026-10-28 12:31 – Updated: 2026-10-28 12:31In 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": [],
"aliases": [
"CVE-2026-99140"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-28T11:17:33Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix hist trigger timestamps for buffered events\n\nSyzkaller triggered a WARN_ON_ONCE(!nest) warning:\n\n WARNING: kernel/trace/ring_buffer.c:821 at ring_buffer_event_time_stamp\n Call trace:\n ring_buffer_event_time_stamp\n hist_field_timestamp\n hist_fn_call\n event_hist_trigger\n event_triggers_call\n __event_trigger_test_discard\n trace_event_buffer_commit\n do_trace_event_raw_event_sched_switch\n trace_event_raw_event_sched_switch\n\nThe warning is probabilistically reproducible and is related to syzkaller\nexecuting the following commands:\n\n echo \u0027prev_pid == 999999\u0027 \u003e events/sched/sched_switch/filter\n echo \u0027hist:keys=common_timestamp\u0027 \u003e events/sched/sched_switch/trigger\n\nThe specific triggering process is as follows:\n\nCPU 0 CPU 1\n(context switching) (echo \u0027hist:keys=common_timestamp\u0027 \u003e \\\n events/sched/sched_switch/trigger)\ndo_trace_event_raw_event_##call\n trace_event_buffer_lock_reserve\n if (!tr-\u003eno_filter_buffering_ref \u0026\u0026\n trace_file-\u003eflags \u0026 EVENT_FILE_FL_FILTERED)\n return entry; // return directly\n event_hist_trigger_parse\n hist_register_trigger\n tracing_set_filter_buffering(file-\u003etr, true);\n tr-\u003eno_filter_buffering_ref++;\n __trace_buffer_lock_reserve\n rb_start_commit\n local_inc(\u0026cpu_buffer-\u003ecommitting); // skipped and not executed\n trace_event_buffer_commit\n __event_trigger_test_discard\n event_triggers_call\n event_hist_trigger\n hist_fn_call\n hist_field_timestamp\n ring_buffer_event_time_stamp\n nest = local_read(\u0026cpu_buffer-\u003ecommitting);\n WARN_ON_ONCE(!nest) // trigger warning\n\nThe root cause is that when an event file has a filter attached and the\nhist trigger has not yet been attached, trace_event_buffer_lock_reserve()\nwrites the event into the per-CPU trace_buffered_event temp buffer instead\nof reserving it in the ring buffer, so cpu_buffer-\u003ecommitting is not\nincremented. When the event is later processed at commit time by a hist\ntrigger, hist_field_timestamp() -\u003e ring_buffer_event_time_stamp() sees a\nzero committing count, triggering WARN_ON_ONCE(!nest).\n\ntracing_event_time_stamp() was added by commit d8279bfc5e959 (\"tracing:\nAdd tracing_event_time_stamp() API\") for exactly this case: if the event\nis the per-CPU trace_buffered_event, it returns the current ring buffer\ntimestamp. But it never gained a caller. Use it in hist_field_timestamp(),\nso that a hist trigger that races onto a buffered event records the\ncurrent time, which is only marginally later than when the event was\nrecorded, instead of warning and recording a bogus timestamp.",
"id": "GHSA-jpcj-q7f6-fxvj",
"modified": "2026-10-28T12:31:04Z",
"published": "2026-10-28T12:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99140"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/09c7cce2e59e6b3b1807520bcb1980c561f15d1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/89e90b16aadd6e66bd0323bc8dfc76a62e756b57"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9414ca3b99e5a7f1f3bf51c2a01b383e1b355dd0"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.