{"id":"CVE-2026-97936","title":"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 f…","summary":"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 f…","severity":"none","vendor":"Linux","product":"Linux","affected":["Linux >= cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314 < e183b84968d4a6ea476d806ea97668405aa56880","Linux >= cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314 < 57bfc2a17954d173d2a4182f3b582ffbb23aff64","Linux >= cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314 < 55caaf25da2c2bb9b75307e4c868726cb954b1d6","Linux >= cc5fc8bfc961eeb99b7e8dffbeff7a3f6995d314 < a5e70ba87ca8ebc79b4e63de302d03b0625fe153","Linux 6.3"],"published":"2026-09-25","updated":"2026-09-25","sourceUpdated":"2026-09-25T11:17:20.963","source":"NVD","sourceUrl":"https://nvd.nist.gov/vuln/detail/CVE-2026-97936","references":[{"url":"https://git.kernel.org/stable/c/55caaf25da2c2bb9b75307e4c868726cb954b1d6","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/57bfc2a17954d173d2a4182f3b582ffbb23aff64","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/a5e70ba87ca8ebc79b4e63de302d03b0625fe153","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"},{"url":"https://git.kernel.org/stable/c/e183b84968d4a6ea476d806ea97668405aa56880","label":"416baaa9-dc9f-4396-8d5f-8c081fb06d67"}],"tags":["nvd","cve.org"],"ingestedAt":"2026-09-25T11:06:38.883Z","slug":"CVE-2026-97936","body":"## Overview\n\nIn 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 'hist:keys=parent_pid.stacktrace' > 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   </IRQ>\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.\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.","depth":"sunlit","depthScore":3,"depthScoreParts":{"impact":2.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}