{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.111-1"
            }
          ],
          "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: Keep the entry count when the histogram stats allocation fails  print_entries() uses n_entries both as the number of sort entries and as its own return value, so the -ENOMEM it stores when the stats allocation fails overwrites the count that the cleanup still needs:  \tn_entries = tracing_map_sort_entries(map, ...); \tif (n_entries \u003c 0) \t\treturn n_entries; \t... \t\t\tif (!stats) { \t\t\t\tn_entries = -ENOMEM; \t\t\t\tgoto out; \t\t\t} \t...  out: \ttracing_map_destroy_sort_entries(sort_entries, n_entries);  tracing_map_destroy_sort_entries() takes an unsigned int and loops up to it, so -ENOMEM arrives as 4294967284. It walks an array of at most map-\u003emax_elts pointers and calls destroy_sort_entry(), which dereferences and frees, on whatever lies past the end.  Reading the hist file of a trigger with a .percent value, with that allocation forced to fail:    BUG: KASAN: vmalloc-out-of-bounds in tracing_map_destroy_sort_entries+0xa0/0xb0   Read of size 8 at addr ffffc90000045000 by task init/1    tracing_map_destroy_sort_entries+0xa0/0xb0    hist_show+0x6f7/0x1df0    seq_read_iter+0x2b8/0x1190    vfs_read+0x176/0xa40   The buggy address belongs to a 4-page vmalloc region starting at   ffffc90000041000 allocated at tracing_map_sort_entries+0x5c/0xd50  A few pages further the fault is fatal. The registers at the oops confirm the bound: the loop's end pointer less the array start, over the pointer size, is 4294967284.  Return the error in a separate variable and leave n_entries holding the count, the way tracing_map_sort_entries() does on its own error path.  The stats block is only entered for a value carrying .percent or .graph, which __create_val_field() has rejected since v6.3, so this cannot be reached in mainline as it stands. It becomes reachable again with \"tracing: hist: let values keep the percent and graph modifiers\", so it should be applied first.",
  "id": "DEBIAN-CVE-2026-97920",
  "modified": "2026-09-29T10:47:32.062761695Z",
  "published": "2026-09-25T11:17:19.037Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-97920"
    }
  ],
  "upstream": [
    "CVE-2026-97920"
  ]
}