[CVE-2026-89918][MODERATE 7.0] KVM: arm64: Correctly handle end of VA space TLBI invalidation

[CVE-2026-89918][MODERATE 7.0] KVM: arm64: Correctly handle end of VA space TLBI invalidation

[AL-KERNEL]

CVE: CVE-2026-89918
Priority: MODERATE 7.0
AL-KERNEL base severity: MODERATE
KPANIC flag: YES
Patch: KVM: arm64: Correctly handle end of VA space TLBI invalidation
Commit: ce447651a52ec077694172af10c4fffb11f56c43
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ce447651a52ec077694172af10c4fffb11f56c43
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-89918
Analysis date: Wed, 16 Sep 2026 14:53:53 -0400
ActionableScore: 5
ActionableScore lower bound: 4
Actionable bucket: Actionable Moderate / Strong Important candidate requiring manual review
Manual review required: YES

Summary:
No one-sentence report phrase was found.

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

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

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 7.0
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-89918	MODERATE	https://www.kernelcve.org/list/?q=CVE-2026-89918 CHECK WITH IMPACT FROM ORIG NN MODERATE	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-190;CWE-682;CWE-697;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H';BEST CVSS score: '7';DESCR 'KVM arm64 nested virtualization can miss a VA based TLBI invalidation at the end of the TTBR1 VA space because the range comparison used base plus size and did not handle address rollover. A guest controlled TLBI range that reaches the end of the VA space may therefore leave a stale VNCR TLB entry active and later KVM code may use an obsolete translation. For the CVSS the PR:L value is used because reliable triggering requires local KVM access or control of a guest context rather than a remote packet only interface. The issue is not directly network reachable and depends on arm64 nested virtualization support and the affected VNCR TLBI path. Impact is at least denial of service or guest memory integrity impact from stale translation use. For the paranoid score, the highest still defensible interpretation is used because stale KVM MMU translations can be a memory corruption candidate and should not be autoclosed without manual review.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Actionable Moderate / Strong Important candidate requiring manual review (with actual score 5) 	MAYBE	OOB VIRT SIMPLEFIX RACE HARDWARE LINUS KPANIC 	-	-	checked

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

ActionableScore=5
ActionableScoreLower=4
PrimitiveClass=CLASS_B
RealUAF=NO
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=YES
ManualReview=REQUIRED
AutoDowngradeAllowed=NO

1. ActionableScore

* Raw conservative score: 4
* Conservative score: 4
* Raw paranoid score: 5
* Paranoid score: 5
* Final recommended bucket: **Actionable Moderate / Strong Important candidate requiring manual review**::

No floor or cap was applied. The paranoid score is used as ActionableScore because the bug affects active KVM translation state and the full impact of stale VNCR TLB entries is unresolved.

2. Signal breakdown

Conservative signals:

* +1 Weak or indirect corruption candidate. The patch establishes that VA range rollover can cause KVM to miss a required VNCR TLB invalidation, leaving obsolete translation state active.
* +1 Active state invalidation failure. A live TLB entry that should be invalidated by a TLBI operation can remain valid because the old range comparison used `base + size` and wrapped to zero.
* +1 Active translation synchronization signal. The affected state is not passive metadata. It is host-maintained nested virtualization translation state that may be used by later KVM execution.
* +1 Security-sensitive KVM MMU context. The bug is in KVM arm64 nested virtualization TLB handling, which is a security-sensitive guest/host boundary area, even though this alone does not prove guest-to-host compromise.

Paranoid additional signal:

* +1 Unresolved stale-translation impact. A stale host-maintained translation in KVM MMU/TLB state can plausibly affect guest memory correctness, integrity, or availability, and should not be automatically closed without manual review.

Important non-awarded signals:

* RealUAF not awarded. This is stale translation state, not a demonstrated heap object use-after-free.
* Strong exploitation leverage +2 not awarded. No controlled reclaim, arbitrary host read/write, callback control, or demonstrated guest-to-host corruption primitive is shown.
* Reliable kernel crash +1 not awarded. The commit establishes failed invalidation, but does not show a concrete host panic or crash trace.
* Remote reachability +2 not awarded. The path is KVM/local virtualization, not packet-driven network input.
* Local unprivileged trigger +1 not awarded. Reachability requires KVM guest/VMM context, not an ordinary syscall path available to every local user.
* KVM guest-to-host strong leverage not awarded. Guest influence plus host KVM state plus virtualization boundary is not sufficient by itself under the KVM calibration rule.
* C/I impact points not awarded as direct evidence. Stale translation makes C/I plausible enough for paranoid review, but no concrete unauthorized host memory read/write is established.
* Race penalty not awarded. The issue is arithmetic rollover in range comparison, not a hard timing race.
* Rare hardware penalty not awarded. arm64 nested virtualization is a specific configuration, but the supplied evidence does not justify treating it as physical-only or rare hardware.

3. Reachability analysis

The evaluated attacker is a local KVM or guest-context attacker, not a remote network attacker. A malicious guest may be able to issue the TLBI operation once an affected nested virtualization setup exists. A local VMM process with access to `/dev/kvm` can also create and run guest state that reaches this path.

Host administrator privilege is not positively established as required for the vulnerable operation, because KVM access may be delegated to non-root users through the usual KVM device permissions. Therefore HostAdminRequired=NO, but this is not ordinary unprivileged reachability.

NamespaceScopedPrivilege=NO because this is not a namespace-scoped capability path. There is no evidence that user or network namespaces independently provide the complete trigger chain.

The bug depends on arm64 KVM nested virtualization support and the VNCR/NV2 TLBI path. Prior VM setup is required in practice, but the actual invalidation failure is tied to guest/KVM translation behavior rather than host-admin-only maintenance.

This is not a race. Repeatability depends on whether the attacker can construct TLBI ranges reaching the end of the TTBR1 VA space in the affected nested virtualization mode.

4. Primitive and severity interpretation

The exact primitive is an arithmetic rollover in KVM arm64 nested TLBI range intersection logic. The old code compared against an exclusive end address computed as `base + size`. At the end of the TTBR1 VA space this can wrap to zero, causing KVM to decide that an affected VNCR TLB entry does not intersect the invalidation scope.

This is an active translation-state bug, not fixed stale storage and not a cleanup-only stale dereference. It does not establish a concrete repeated release/refcount operation. No first lifetime release, surviving exact reference, or second lifetime mutation exists here.

PrimitiveClass=CLASS_B because the bug leaves active host-maintained KVM translation state stale after a required invalidation. It is stronger than a passive logic bug, but weaker than CLASS_A because no arbitrary write, controlled reclaim, demonstrated host memory corruption, or concrete guest-to-host escape is shown.

The demonstrated consequence is failed TLB invalidation. The speculative consequence is stale translation use causing guest memory correctness or integrity problems, host-side KVM faulting, or other virtualization boundary issues. The leverage beyond crash remains unresolved.

ImportantCandidate=YES because KVM MMU stale translation bugs are security-sensitive and the patch establishes a real active-state invalidation failure. AutoDowngradeAllowed=NO because automatically closing this as ordinary Moderate would discard a meaningful unresolved KVM translation-state primitive.

Operationally, this is best treated as Actionable Moderate at minimum, with Strong Important review depending on whether additional analysis shows stale translation can be used for guest-to-host corruption, unauthorized memory access, or reliable host DoS.

5. One-sentence report phrase

A VA range rollover bug in KVM arm64 nested TLBI handling can skip VNCR TLB invalidation at the end of TTBR1 VA space, leaving stale host-maintained translation state reachable from a local KVM or guest context.

6. Manual review recommendation

MANUAL CHECK REQUIRED

Manual review is required because the patch fixes a missed invalidation of active KVM translation state, and the security impact of stale VNCR TLB entries is not safely reducible to ordinary crash-only behavior from the supplied patch alone.

7. Call-site confidence

Call-site confidence: medium

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

Patch: KVM: arm64: Correctly handle end of VA space TLBI invalidation
Commit: ce447651a52ec077694172af10c4fffb11f56c43
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ce447651a52ec077694172af10c4fffb11f56c43

Commit description:

Our TLB invalidation by VA code is based on comparing two ranges,
one defined by the TLB, and one defined by the TLBI instruction.

Each range is defined by a start and a size. However, the way the
comparison is done doesn't account for address rollover, as it
compares an address with (base + size). This works nicely until
this expression represent the last page/block in the TTBR1 VA space,
as the result is a big fat 0. And a failed TLB invalidation.

Rewrite the comparison in a way that is immune to the address
rollover (making the end address inclusive instead of exclusive),
and move this into a common helper that is used by both VA and IPA
invalidations, as suggested by Hyunwoo Kim (although the IPA version
didn't suffer from this particular problem, obviously).

Fixes: 4ffa72a ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2")
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260806091026.620700-5-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed files:
  arch/arm64/kvm/nested.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=ce447651a52ec077694172af10c4fffb11f56c43

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

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

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:L/UI:N/S:U/C:L/I:L/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: 4
  Paranoid ActionableScore: 5

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: YES
Published priority for this report (same as in Subject): MODERATE 7.0

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).