CVE-2026-97935
Last modified
CVE-2026-97935 is a vulnerability of currently unknown severity. In the Linux kernel, the following vulnerability has been resolved: tracing: Set the trace clock before registering the histogram trigger hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock: if (data->cmd_ops->init) { ret = data->cmd_ops->init(data); if (ret < 0) goto out; } if (hist_data->enable_timestamps) { ret = tracing_set_clock(file->tr, hist_data->attrs->clock); if (ret) { hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); goto out; } The clock string is not checked anywhere before that call, so a named trigger using common_timestamp with an unknown clock fails after it has already become findable. event_hist_trigger_parse() 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/sched_switch ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=common_pid' > trigger BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0x900 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 63: kfree+0x154/0x420 trigger_kthread_fn+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 named_triggers list") moved the registration below the rest of the setup. tracing_set_filter_buffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first..
Description
In the Linux kernel, the following vulnerability has been resolved: tracing: Set the trace clock before registering the histogram trigger hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock: if (data->cmd_ops->init) { ret = data->cmd_ops->init(data); if (ret < 0) goto out; } if (hist_data->enable_timestamps) { ret = tracing_set_clock(file->tr, hist_data->attrs->clock); if (ret) { hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); goto out; } The clock string is not checked anywhere before that call, so a named trigger using common_timestamp with an unknown clock fails after it has already become findable. event_hist_trigger_parse() 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/sched_switch ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=foo:keys=common_pid' > trigger BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0 Read of size 8 at addr ffff88800915d760 by task init/1 find_named_trigger+0xac/0xc0 hist_register_trigger+0xc1/0x900 event_hist_trigger_parse+0x3146/0x6af0 event_trigger_write+0xce/0x160 Freed by task 63: kfree+0x154/0x420 trigger_kthread_fn+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 named_triggers list") moved the registration below the rest of the setup. tracing_set_filter_buffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first.
Affected Software
Source: CNA advisory (CVE.org). NVD analysis pending.
| Vendor | Product | Versions |
|---|---|---|
| Linux | Linux | >= a4072fe85ba3671720cab0788291af953db27318, < cfad128171f8e2237a3c723d6478ef2cfb3b9127; >= a4072fe85ba3671720cab0788291af953db27318, < 65d1e28198f344832a8a63e8ccf84b8f65b92a32; >= a4072fe85ba3671720cab0788291af953db27318, < 6ede78d0563a2a3ae3e46f9c07cedb5d79645429 |
| Linux | Linux | 4.17 |
References
Timeline
- Published
- Last Modified
- Status
- Received
Frequently Asked Questions
What is CVE-2026-97935?
How severe is CVE-2026-97935?
How do I fix CVE-2026-97935?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2026
- CVE-2026-9793A flaw was found in Keycloak. When a JSON Web Encryption (JW…7.5
- CVE-2026-97930In the Linux kernel, the following vulnerability has been re…
- CVE-2026-97931In the Linux kernel, the following vulnerability has been re…7
- CVE-2026-97932In the Linux kernel, the following vulnerability has been re…
- CVE-2026-97933In the Linux kernel, the following vulnerability has been re…
- CVE-2026-97934In the Linux kernel, the following vulnerability has been re…
- CVE-2026-97936In the Linux kernel, the following vulnerability has been re…
- CVE-2026-97937In the Linux kernel, the following vulnerability has been re…7.8
- CVE-2026-97938In the Linux kernel, the following vulnerability has been re…
- CVE-2026-97939In the Linux kernel, the following vulnerability has been re…
- CVE-2026-9794A flaw was found in Keycloak. A remote, unauthenticated atta…5.3
- CVE-2026-97940In the Linux kernel, the following vulnerability has been re…7.8
Are you affected by CVE-2026-97935?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
