From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-97920][MODERATE REGULAR] tracing: Keep the entry count when the histogram stats allocation fails Date: Fri, 25 Sep 2026 13:34:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-97920 X-AL-KERNEL-Priority: MODERATE REGULAR X-AL-KERNEL-Severity: MODERATE REGULAR X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 3 X-AL-KERNEL-ActionableScore-Lower: unknown X-AL-KERNEL-Commit: 9bd8321f5370295d1ae96dd17d43be3c9edd441b List-Id: 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 Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman 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).