GHSA-7W7W-22GX-H2R2
Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 12:31In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix memory corruption from the histogram stacktrace modifier
parse_field() sets HIST_FIELD_FL_STACKTRACE from the ".stacktrace" modifier before it looks the field name up, and nothing afterwards checks that the name resolved to a field which holds a stacktrace. create_hist_field() picks HIST_FIELD_FN_STACK on the strength of the field pointer alone, which reads a __data_loc word from the record and follows its low 16 bits as an offset into the same record. event_hist_trigger() takes the first word there as an entry count and copies that many longs into a 31 entry array:
n_entries = *stack;
memcpy(entries, ++stack, n_entries * sizeof(unsigned long));
Neither end of that copy is bounded, and the count is whatever the event holds at the offset, so any field will do:
# cd /sys/kernel/tracing/events/sched/sched_process_fork # echo 'hist:keys=parent_pid.stacktrace' > trigger # (true)
BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:rb_insert_color+0x18/0x130 timerqueue_linked_add+0x7e/0xd0 enqueue_hrtimer+0x39/0xb0 __hrtimer_run_queues+0x10f/0x1f0 RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x165/0x690
The timer interrupt landed on the rbtree the copy had already run over. No debug options are needed for this; KASAN reports the same write as an out-of-bounds read of 13835058055416381440 bytes.
Documentation/trace/histogram.rst already states the rule, "must be a long[] type", so enforce it once the name has been resolved. Names which resolve to no field at all, "hitcount.stacktrace" and the common_* pseudo-fields, are refused for the same reason: they hold no stacktrace to read.
{
"affected": [],
"aliases": [
"CVE-2026-97936"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T11:17:20Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix memory corruption from the histogram stacktrace modifier\n\nparse_field() sets HIST_FIELD_FL_STACKTRACE from the \".stacktrace\"\nmodifier before it looks the field name up, and nothing afterwards\nchecks that the name resolved to a field which holds a stacktrace.\ncreate_hist_field() picks HIST_FIELD_FN_STACK on the strength of the\nfield pointer alone, which reads a __data_loc word from the record and\nfollows its low 16 bits as an offset into the same record.\nevent_hist_trigger() takes the first word there as an entry count and\ncopies that many longs into a 31 entry array:\n\n\tn_entries = *stack;\n\tmemcpy(entries, ++stack, n_entries * sizeof(unsigned long));\n\nNeither end of that copy is bounded, and the count is whatever the event\nholds at the offset, so any field will do:\n\n # cd /sys/kernel/tracing/events/sched/sched_process_fork\n # echo \u0027hist:keys=parent_pid.stacktrace\u0027 \u003e trigger\n # (true)\n\n BUG: kernel NULL pointer dereference, address: 0000000000000008\n RIP: 0010:rb_insert_color+0x18/0x130\n timerqueue_linked_add+0x7e/0xd0\n enqueue_hrtimer+0x39/0xb0\n __hrtimer_run_queues+0x10f/0x1f0\n \u003c/IRQ\u003e\n RIP: 0010:memcpy+0xc/0x30\n event_hist_trigger+0x165/0x690\n\nThe timer interrupt landed on the rbtree the copy had already run over.\nNo debug options are needed for this; KASAN reports the same write as an\nout-of-bounds read of 13835058055416381440 bytes.\n\nDocumentation/trace/histogram.rst already states the rule, \"must be a\nlong[] type\", so enforce it once the name has been resolved. Names which\nresolve to no field at all, \"hitcount.stacktrace\" and the common_*\npseudo-fields, are refused for the same reason: they hold no stacktrace\nto read.",
"id": "GHSA-7w7w-22gx-h2r2",
"modified": "2026-09-25T12:31:29Z",
"published": "2026-09-25T12:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97936"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/55caaf25da2c2bb9b75307e4c868726cb954b1d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/57bfc2a17954d173d2a4182f3b582ffbb23aff64"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5e70ba87ca8ebc79b4e63de302d03b0625fe153"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e183b84968d4a6ea476d806ea97668405aa56880"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.
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.