[CVE-2026-97920][MODERATE REGULAR] tracing: Keep the entry count when the histogram stats allocation fails

[CVE-2026-97920][MODERATE REGULAR] tracing: Keep the entry count when the histogram stats allocation fails

[AL-KERNEL]

CVE: CVE-2026-97920
Priority: MODERATE REGULAR
AL-KERNEL base severity: MODERATE
KPANIC flag: NO
Patch: tracing: Keep the entry count when the histogram stats allocation fails
Commit: 9bd8321f5370295d1ae96dd17d43be3c9edd441b
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9bd8321f5370295d1ae96dd17d43be3c9edd441b
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-97920
Analysis date: Fri, 25 Sep 2026 13:34:43 -0400
ActionableScore: 3
ActionableScore lower bound: unknown
Actionable bucket: Borderline / manual review recommended
Manual review required: YES

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2026-97920 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-97920

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE REGULAR
Manual review required: YES

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2026-97920	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-97920 CHECK WITH IMPACT FROM ORIG NN LOW	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H';CWE-681;CWE-125;CWE-590;*CWE-787;Other CVSS 'AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H';BEST CVSS score: '7';DESCR 'An allocation failure in tracing histogram output can replace the valid entry count with ENOMEM. The negative error is then converted to a very large unsigned count by tracing_map_destroy_sort_entries(), causing cleanup to walk beyond the allocated sort entry array. Out of bounds values are interpreted as pointers and are passed to destroy_sort_entry(), which can dereference and free invalid objects. The demonstrated result is a fatal KASAN vmalloc out of bounds fault and kernel denial of service. The cleanup behavior also creates a plausible memory corruption and invalid free risk, so confidentiality and integrity impact cannot be excluded in the paranoid assessment. For the CVSS the PR:L value is used for the paranoid score because a local user may only need permission to read an already configured histogram file and invoke hist_show, although creating the histogram trigger normally requires administrative tracing privileges. AC:H applies because exploitation depends on a percent or graph histogram value, a stats allocation failure, and favorable memory contents beyond the array. The path is not reachable in current mainline without the related change that restores percent and graph modifiers, but it can affect compatible stable code or become reachable when that change is applied. The issue is local and is not network reachable.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Borderline / manual review recommended (with actual score 3)  SKIP CVE-2026-97920 UNKNOWN SKIP The Fixes patch not applied yet, so unlikely that actual: url YES  NO NO unknown 	MAYBE	READ KASAN OOB TRACE NOMEMCHK ERRORPATH LINUS  INCREASED_FROM_LOW_BASED_ON_REQUIREMANUALCHECK DECREASED_TO_MODERATEREG_BASED_ON_ACTIONABLESCORELESSTHAN4	-	-	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=3
PrimitiveClass=CLASS_B
RealUAF=NO
HostAdminRequired=UNKNOWN
NamespaceScopedPrivilege=NO
ImportantCandidate=NO
ManualReview=RECOMMENDED
AutoDowngradeAllowed=YES

1. ActionableScore

* Raw conservative score: 3
* Conservative score: 3
* Raw paranoid score: 3
* Paranoid score: 3
* No floor or cap was applied.
* Final recommended bucket: **Borderline / manual review recommended**::

2. Signal breakdown

* +1 Weak or indirect corruption candidate. The signed error value becomes an unsigned count, causing a concrete out-of-bounds traversal of the sort-entry pointer array.
* +1 Weak LPE concern. Out-of-bounds values are not merely read. They are interpreted as structured pointers and passed to a destructor that dereferences and frees objects. This is an uncontrolled invalid-free sink, although no useful target selection is demonstrated.
* +1 Reliable kernel crash. KASAN confirms a fatal vmalloc out-of-bounds access, and the unchecked loop can continue far beyond the allocation without KASAN.
* No privilege penalty was applied because the complete privilege boundary is unresolved. Histogram configuration is normally restricted, but the supplied evidence does not prove that every triggering read requires host-admin-equivalent privilege.
* No race penalty was applied. This is a deterministic error-path sequence, not a timing race.
* No remote-reachability, local-unprivileged, controlled-reclaim, arbitrary-write, disclosure, or integrity bonus was awarded.
* Real UAF was not awarded. The patch establishes an out-of-bounds pointer walk and possible invalid frees, but not a subsequent use of an object after its lifetime ended.
* Strong corruption was not awarded because the attacker cannot demonstrably select the out-of-bounds pointer values or the objects passed to the destructor.
* Extra Availability was not awarded because it would double-count the same fatal fault.
* The paranoid score was not increased merely from the possibility that an invalid free could theoretically be developed into stronger corruption.

3. Reachability analysis

The vulnerable operation is reached while reading a tracing histogram containing a percent or graph value after the statistics allocation fails. Creating and configuring tracing histogram triggers is normally restricted through tracefs, while read access can be delegated by permissions. The evidence does not establish whether a below-host-admin actor can perform the complete configuration and trigger sequence, so HostAdminRequired remains UNKNOWN.

Tracing control is not an attacker-created user-namespace capability path, so NamespaceScopedPrivilege is NO. A previously configured trigger may constitute prior privileged setup, but delegated read access and reliable induction of the allocation failure are not established.

The path is unreachable in current mainline as described because percent and graph modifiers have been rejected since Linux 6.3. It is relevant to older compatible trees or when the companion change restoring those modifiers is applied. No special hardware, network exposure, or race timing is involved.

4. Primitive and severity interpretation

The exact primitive is a signed-to-unsigned count conversion followed by an effectively unbounded out-of-bounds traversal of an allocated pointer array. Each fetched value may be treated as a `tracing_map_sort_entry` pointer and passed to `destroy_sort_entry()`, creating a possible invalid dereference and invalid free.

This is CLASS_B rather than CLASS_A. The cleanup operation can mutate object lifetime by freeing an unintended object, but the supplied evidence does not demonstrate attacker-directed target selection, controlled adjacent contents, controlled reclaim, arbitrary kernel read or write, callback influence, or privilege escalation. It is not a repeated release of a known dangling reference and therefore does not qualify for the repeated-release signal or UAF floor.

The demonstrated consequence is a kernel Oops and denial of service. Stronger memory corruption is technically plausible because cleanup may process non-array pointers, but useful exploitation leverage is unresolved and substantially constrained. ImportantCandidate is therefore NO. AutoDowngradeAllowed is YES because the established behavior remains an uncontrolled cleanup corruption path with crash as the demonstrated result and no independent security-boundary primitive.

5. One-sentence report phrase

A tracing histogram allocation failure can turn an error into a huge cleanup count, causing an out-of-bounds pointer walk and possible invalid frees, with kernel crash demonstrated but no controlled corruption or privilege escalation established.

6. Manual review recommendation

MANUAL CHECK RECOMMENDED

Confirm affected-version reachability, tracefs permissions, whether a low-privilege reader can invoke the configured histogram, and whether adjacent vmalloc contents can produce repeatable valid pointers for unintended destruction.

7. Call-site confidence

Call-site confidence: high

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: tracing: Keep the entry count when the histogram stats allocation fails
Commit: 9bd8321f5370295d1ae96dd17d43be3c9edd441b
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9bd8321f5370295d1ae96dd17d43be3c9edd441b

Commit description:

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.

Cc: stable@vger.kernel.org
Fixes: abaa525 ("tracing: Add .percent suffix option to histogram values")
Link: https://patch.msgid.link/20260907060323.480728-1-donggeunyoo.kernel@gmail.com
Reported-by: sashiko-bot@kernel.org
Closes: https://lore.kernel.org/all/20260907053113.1CED91F00A3A@smtp.kernel.org/
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  kernel/trace/trace_events_hist.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9bd8321f5370295d1ae96dd17d43be3c9edd441b

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2026-97920 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-97920

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
  The Best / paranoid CVSS score: 7

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: unknown
  Paranoid ActionableScore: 3

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: NO
Published priority for this report (same as in Subject): MODERATE REGULAR

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).