Description
In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry

A VNCR TLB invalidation can occur on one vcpu while another vcpu is
faulting in this same page. Without correctly handling this, we can
end up with the following scenario:

- vcpu A walks the PTs to translate VNCR
- before vcpu A is able to grab the MMU lock to insert the TLB,
vcpu B updates the S1 PTs with an invalid entry, and issues
a TLBI S1E2 for this VA
- vcpu A inserts the TLB for something that is now invalid

This isn't a new problem, and we manage S2 by having the MMU notifier
to bump up mmu_invalidate_seq on invalidation so that the fault can be
replayed.

We can perform something similar here, and extend invalidate_vncr_va() to
update the same counter, clearly indicating that the context has
changed under our feet. This is safe as the invalidation always happen
while holding the MMU lock for write, and that we sample the sequence
number before walking S1.
Published: 2026-09-16
Score: 9.3 Critical
EPSS: < 1% Very Low
KEV: No
Impact: Privilege Escalation
Action: Apply Patch
AI Analysis

Impact

A race condition in the Linux kernel’s KVM arm64 TLB invalidation routine can cause a virtual CPU to load a stale or invalid page translation after another virtual CPU updates page tables and issues a TLBI. This flaw may allow a malicious guest to read or execute memory that belongs to another guest or to the host, thereby bypassing isolation guarantees. The weakness is a concurrency error that can lead to uncontrolled memory access or execution, representing a high‑impact privilege escalation scenario.

Affected Systems

This vulnerability affects Linux kernels running on ARM64 architecture that employ KVM virtualization. All systems that use the kernel version with the flawed VNCR invalidation path are impacted, regardless of additional distribution patches. The specific kernel commits referenced by the advisory fix the issue in newer patches; older releases lacking those commits remain vulnerable.

Risk and Exploitability

The CVSS score of 9.3 indicates critical severity. The EPSS score of less than 1% suggests that exploitation is unlikely in the near term, and the vulnerability is not currently listed in the CISA KEV catalog. The attack vector would be a malicious virtual machine that can perform rapid page table changes. Compromise requires the guest to have control over S1 page tables, which is typically confined within the guest environment, so the exploitation risk is limited to hosts running vulnerable, unpatched kernels.

Generated by OpenCVE AI on September 18, 2026 at 03:37 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade to a Linux kernel release that includes the KVM arm64 VNCR invalidation fix (e.g., the commit identified in the advisory or any downstream patch set that references that commit).
  • Reboot the host to activate the updated kernel and restart all KVM guests so they enter the protected memory management path.
  • If an immediate kernel upgrade is not feasible, restrict or monitor guest workloads that perform heavy page table updates or S1 faulting until the patch is applied; consider disabling or limiting such operations as a temporary containment measure.

Generated by OpenCVE AI on September 18, 2026 at 03:37 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 18 Sep 2026 04:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362

Wed, 16 Sep 2026 14:45:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

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


Wed, 16 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry A VNCR TLB invalidation can occur on one vcpu while another vcpu is faulting in this same page. Without correctly handling this, we can end up with the following scenario: - vcpu A walks the PTs to translate VNCR - before vcpu A is able to grab the MMU lock to insert the TLB, vcpu B updates the S1 PTs with an invalid entry, and issues a TLBI S1E2 for this VA - vcpu A inserts the TLB for something that is now invalid This isn't a new problem, and we manage S2 by having the MMU notifier to bump up mmu_invalidate_seq on invalidation so that the fault can be replayed. We can perform something similar here, and extend invalidate_vncr_va() to update the same counter, clearly indicating that the context has changed under our feet. This is safe as the invalidation always happen while holding the MMU lock for write, and that we sample the sequence number before walking S1.
Title KVM: arm64: Make VNCR invalidation participate in MMU invalidation retry
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-09-16T14:40:09.360Z

Reserved: 2026-09-11T19:38:34.775Z

Link: CVE-2026-89916

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-16T11:17:00.657

Modified: 2026-09-16T15:18:17.883

Link: CVE-2026-89916

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-18T03:45:01Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')