{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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:  \tn_entries = *stack; \tmemcpy(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' \u003e 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    \u003c/IRQ\u003e   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.",
  "id": "DEBIAN-CVE-2026-97936",
  "modified": "2026-09-26T04:47:40.788870782Z",
  "published": "2026-09-25T11:17:20.963Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-97936"
    }
  ],
  "upstream": [
    "CVE-2026-97936"
  ]
}