FKIE_CVE-2026-97936
Vulnerability from fkie_nvd - Published: 2026-09-25 11:17 - Updated: 2026-09-25 11:17
Severity
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
</IRQ>
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"kernel/trace/trace_events_hist.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "e183b84968d4a6ea476d806ea97668405aa56880",
"status": "affected",
"version": "cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314",
"versionType": "git"
},
{
"lessThan": "57bfc2a17954d173d2a4182f3b582ffbb23aff64",
"status": "affected",
"version": "cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314",
"versionType": "git"
},
{
"lessThan": "55caaf25da2c2bb9b75307e4c868726cb954b1d6",
"status": "affected",
"version": "cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314",
"versionType": "git"
},
{
"lessThan": "a5e70ba87ca8ebc79b4e63de302d03b0625fe153",
"status": "affected",
"version": "cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"kernel/trace/trace_events_hist.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.3"
},
{
"lessThan": "6.3",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.111",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.53",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3-rc3",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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": "CVE-2026-97936",
"lastModified": "2026-09-25T11:17:20.963",
"metrics": {},
"published": "2026-09-25T11:17:20.963",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/55caaf25da2c2bb9b75307e4c868726cb954b1d6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/57bfc2a17954d173d2a4182f3b582ffbb23aff64"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a5e70ba87ca8ebc79b4e63de302d03b0625fe153"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e183b84968d4a6ea476d806ea97668405aa56880"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
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.
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.
Loading…
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.
Loading…