tracing: Fix memory corruption from the histogram stacktrace modifier
In 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 e
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.111, 6.18.53, 6.6.158, 7.2.7
- CVEs
- CVE-2026-97936
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 16:07 UTC · Revision 1
Source evidence
tracing: Fix memory corruption from the histogram stacktrace modifier
core-osv · Original sourcePublished 25 Sept 2026, 10:22 UTC
In 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 e
osv:CVE-2026-97936
Kernel
Fixed versions: 6.6.158, 6.12.111, 6.18.53, 7.2.7
Complete source record
{
"id": "24f9779a4ea26531b307c2954face1c3fb71a084ff221bf2aec7adecd03337e2",
"url": "https://osv.dev/vulnerability/CVE-2026-97936",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "tracing: Fix memory corruption from the histogram stacktrace modifier",
"summary": "In 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 e",
"evidence": "osv:CVE-2026-97936",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.158",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.111",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.53",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.7",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-97936",
"aliases": [
"CVE-2026-97936"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314"
},
{
"fixed": "98da3379cdee343f671dac89b9afbd8b071f2591"
},
{
"fixed": "e183b84968d4a6ea476d806ea97668405aa56880"
},
{
"fixed": "57bfc2a17954d173d2a4182f3b582ffbb23aff64"
},
{
"fixed": "55caaf25da2c2bb9b75307e4c868726cb954b1d6"
},
{
"fixed": "a5e70ba87ca8ebc79b4e63de302d03b0625fe153"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-97936.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.3.0"
},
{
"fixed": "6.6.158"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.111"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.53"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.2.7"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-97936.json"
}
}
],
"modified": "2026-10-28T02:30:37.193192431Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/55caaf25da2c2bb9b75307e4c868726cb954b1d6",
"https://git.kernel.org/stable/c/57bfc2a17954d173d2a4182f3b582ffbb23aff64",
"https://git.kernel.org/stable/c/98da3379cdee343f671dac89b9afbd8b071f2591",
"https://git.kernel.org/stable/c/a5e70ba87ca8ebc79b4e63de302d03b0625fe153",
"https://git.kernel.org/stable/c/e183b84968d4a6ea476d806ea97668405aa56880",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/97xxx/CVE-2026-97936.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-97936",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/97xxx/CVE-2026-97936.json"
}
},
"related_cves": [
{
"value": "CVE-2026-97936",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 504494,
"published_at": "2026-09-25T10:22:50.446+00:00"
}