CVE Catalog

CVE-2026-97920

Unknown
Published: Translated: NVD NIST

Summary

In the Linux kernel, print_entries() in the tracing/histogram subsystem uses n_entries both as the number of sort entries and as its return value. When the stats allocation fails, the stored -ENOMEM overwrites the count that is later passed to tracing_map_destroy_sort_entries(), which takes an unsigned int and loops up to it, causing an out-of-bounds read and free (vmalloc-out-of-bounds).

Risk Assessment

The flaw causes kernel memory corruption (reading and freeing pointers past the end of the array), which can lead to a system crash (oops/panic) and potentially further security impact. The path is hard to reach in current mainline but becomes reachable once the percent and graph modifier changes are applied.

Recommendation

Apply the kernel fix that stores the error in a separate variable and leaves n_entries holding the count, matching tracing_map_sort_entries() behavior on its error path. This fix should be applied before the "tracing: hist: let values keep the percent and graph modifiers" change.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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: n_entries = tracing_map_sort_entries(map, ...); if (n_entries < 0) return n_entries; ... if (!stats) { n_entries = -ENOMEM; goto out; } ... out: tracing_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->max_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.

Vulnerability data from NVD (NIST) · CISA KEV · EPSS