Description
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.
Published: 2026-09-25
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Kernel crash leading to denial of service
Action: Patch immediately
AI Analysis

Impact

A flaw in the Linux kernel’s tracing subsystem allows a misuse of the negative error code -ENOMEM as an unsigned count in the function tracing_map_destroy_sort_entries(). When the histogram statistics allocation fails, the signed value is incorrectly treated as a large unsigned integer, causing the routine to traverse past the tail of an array and dereference invalid memory. This out‑of‑bounds access triggers a kernel oops and can lead to a denial of service. The bug results in an out‑of‑bounds read (CWE‑125).

Affected Systems

All Linux kernel releases that expose the tracing histogram feature are affected, including those that enable .percent or .graph modifiers in trace values. The issue was refactored in versions prior to Linux 6.3 but becomes reachable again with the “tracing: hist: let values keep the percent and graph modifiers” option is enabled. No specific vendor or product version is listed; the vulnerability exists in the core kernel code.

Risk and Exploitability

The exploit requires the triggering of a tracing histogram with allocation failure, which can be induced by crafted trace data or configuration changes. EPSS score is <1% and the vulnerability is not listed in CISA KEV. The kernel bug’s severity is medium (CVSS 5.5). The likely attack vector is inferred from the description to be local or via a privileged application that uses tracing. Even if currently unreachable in mainstream mainline kernels, newer configurations or patches that re‑enable the problematic paths could expose the flaw.

Generated by OpenCVE AI on October 1, 2026 at 08:44 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that applies the official patch correcting the signed‑to‑unsigned conversion in tracing_map_destroy_sort_entries().
  • If an update is not yet available, disable the use of .percent and .graph modifiers in trace configuration or remove any custom histogram definitions that rely on them.
  • Configure the kernel with tracing disabled or with the CONFIG_TRACE_HISTOGRAM option turned off if the tracing feature is not needed in the environment.

Generated by OpenCVE AI on October 1, 2026 at 08:44 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Sat, 03 Oct 2026 11:15:00 +0000


Thu, 01 Oct 2026 07:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Wed, 30 Sep 2026 00:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-125
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Moderate


Fri, 25 Sep 2026 20:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-665

Fri, 25 Sep 2026 10:30:00 +0000

Type Values Removed Values Added
Description 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.
Title tracing: Keep the entry count when the histogram stats allocation fails
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-03T11:00:32.808Z

Reserved: 2026-09-25T10:18:58.202Z

Link: CVE-2026-97920

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-25T11:17:19.037

Modified: 2026-10-03T11:18:09.677

Link: CVE-2026-97920

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-25T00:00:00Z

Links: CVE-2026-97920 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-01T08:45:03Z

Weaknesses