GHSA-JFP7-C7J3-V9PJ
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 crash in print_graph_function_event()
tracing_set_tracer() assigns the flags of the newly selected tracer with:
tr->current_trace_flags = t->flags ? : t->tracer->flags;
If the new tracer defines neither static flags nor default flags, like hwlat, irqsoff or wakeup, add_tracer() has no per instance flags copy for it, and both operands are NULL, so tr->current_trace_flags ends up being NULL as well.
The ring buffer is not cleared when switching tracers: it is reset inside tracer_init(), after current_trace_flags was already assigned. If the buffer still holds function_graph entries of the previous tracer, printing one of them dereferences the NULL pointer. This was hit by cat trace during an ftrace stress test:
BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:print_graph_function_event+0xe/0x20 Call Trace: s_show+0x4d/0x110 seq_read_iter+0x2d4/0x490 seq_read+0x130/0x170 vfs_read+0xb5/0x370 ksys_read+0x6d/0xe0 do_syscall_64+0xbc/0x450
The snapshot buffer is not reset at all, so this can be reproduced without a race:
echo function_graph > /sys/kernel/tracing/current_tracer echo 1 > /sys/kernel/tracing/snapshot echo hwlat > /sys/kernel/tracing/current_tracer cat /sys/kernel/tracing/snapshot
Rather than teaching every user of tr->current_trace_flags about this corner case, make sure it is never NULL: when the newly selected tracer has no flags at all, tracing_set_tracer() falls back to a static empty no_tracer_flags. run_tracer_selftest() can hit the same case, so the same fallback is added there too. The existing users already handle opts == NULL, so these tracers keep behaving as before.
{
"affected": [],
"aliases": [
"CVE-2026-99141"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-28T11:17:34Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix crash in print_graph_function_event()\n\ntracing_set_tracer() assigns the flags of the newly selected tracer\nwith:\n\n\ttr-\u003ecurrent_trace_flags = t-\u003eflags ? : t-\u003etracer-\u003eflags;\n\nIf the new tracer defines neither static flags nor default flags, like\nhwlat, irqsoff or wakeup, add_tracer() has no per instance flags copy\nfor it, and both operands are NULL, so tr-\u003ecurrent_trace_flags ends up\nbeing NULL as well.\n\nThe ring buffer is not cleared when switching tracers: it is reset\ninside tracer_init(), after current_trace_flags was already assigned.\nIf the buffer still holds function_graph entries of the previous\ntracer, printing one of them dereferences the NULL pointer. This was\nhit by cat trace during an ftrace stress test:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor read access in kernel mode\n RIP: 0010:print_graph_function_event+0xe/0x20\n Call Trace:\n s_show+0x4d/0x110\n seq_read_iter+0x2d4/0x490\n seq_read+0x130/0x170\n vfs_read+0xb5/0x370\n ksys_read+0x6d/0xe0\n do_syscall_64+0xbc/0x450\n\nThe snapshot buffer is not reset at all, so this can be reproduced\nwithout a race:\n\n echo function_graph \u003e /sys/kernel/tracing/current_tracer\n echo 1 \u003e /sys/kernel/tracing/snapshot\n echo hwlat \u003e /sys/kernel/tracing/current_tracer\n cat /sys/kernel/tracing/snapshot\n\nRather than teaching every user of tr-\u003ecurrent_trace_flags about this\ncorner case, make sure it is never NULL: when the newly selected\ntracer has no flags at all, tracing_set_tracer() falls back to a\nstatic empty no_tracer_flags. run_tracer_selftest() can hit the same\ncase, so the same fallback is added there too. The existing users\nalready handle opts == NULL, so these tracers keep behaving as before.",
"id": "GHSA-jfp7-c7j3-v9pj",
"modified": "2026-10-28T12:31:05Z",
"published": "2026-10-28T12:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-99141"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3cc117514d69067a94d6c7479730dce41e678f50"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1547c6ba93b8863010aa324cd20c441f886f23e"
}
],
"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.