CVE-2026-89915 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Remove VM-wide VNCR mapping counter
The global VNCR mapping counter is used to decide whether an L1 provided VNCR page is mapped in L0 on any CPU at the point of dealing with a TLB invalidation. It is incremented when a mapping is made in the fixmap, and decremented when unmapped.
As it turns out, this tracking has several flaws:
- we are trying to invalidate TLBs, and the mapping is only an opportunistic consequence of the TLB. Checking this counter to decide whether a TLB needs to be invalidated may result in missed invalidations.
- an L1 vcpu invalidating its own TLB (a very likely case) will not succeed in invalidating the VNCR pseudo TLB because that page is not mapped in L0 at this stage.
Given that this tracking fails at delivering the minimum guarantees that are required and is only a performance optimisation, remove it completely.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel vulnerability identified within the KVM arm64 subsystem involves a fundamental flaw in how virtual Non-Volatile Control Register (VNCR) mappings are tracked across hypervisor levels. The VNCR mechanism allows for efficient context switching by mapping guest control registers directly into the host address space, thereby avoiding expensive hypercalls during vCPU scheduling transitions. To optimize this process, KVM maintains a global counter that tracks whether an L1 provided VNCR page is currently mapped in L0 on any CPU. This counter is incremented when a mapping is established via fixmap and decremented upon unmapping. The primary purpose of maintaining this state was to determine if TLB invalidations were necessary for these specific mappings, aiming to reduce overhead by skipping unnecessary operations when no active mappings existed.
However, the reliance on this global tracking mechanism introduces significant logical errors that compromise system stability and correctness. The core issue arises because the presence of a VNCR mapping is often an opportunistic consequence of TLB behavior rather than a strictly synchronized state indicator. When attempting to invalidate TLBs for these mapped pages, checking the counter can lead to missed invalidations if the count does not accurately reflect real-time memory management states across all CPUs. This discrepancy means that stale entries may remain in the Translation Lookaside Buffer, potentially causing data corruption or incorrect execution paths as the guest accesses outdated virtual-to-physical address translations.
A more critical failure mode occurs when an L1 vCPU attempts to invalidate its own TLB. In such scenarios, which are highly probable during normal operation, the VNCR page may not be mapped in L0 at that specific stage of execution. Consequently, the invalidation request fails because there is no active mapping to target for TLB purge operations. This failure prevents the proper cleanup of stale translations associated with the vCPU's control registers, leading to potential security risks where a malicious or buggy guest could exploit these inconsistencies to maintain access to resources it should have been locked out of, or cause denial-of-service conditions through unpredictable kernel behavior resulting from inconsistent state management.
The resolution involves completely removing this flawed tracking mechanism since it fails to deliver the minimum guarantees required for correct TLB maintenance and serves only as a performance optimization that introduces more risk than benefit. By eliminating the counter-based decision logic, KVM ensures that TLB invalidations are handled through more robust mechanisms that do not depend on potentially inaccurate global state indicators. This change aligns with best practices in virtualization security by prioritizing correctness over marginal performance gains, ensuring that memory management operations remain reliable even under high contention or rapid context switching scenarios typical in cloud computing environments.
From a vulnerability classification perspective, this issue relates to CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization, as the global counter is accessed and modified by multiple CPUs without sufficient guarantees of atomicity or consistency relative to TLB state changes. It also touches upon CWE-457 Use of Uninitialized Variable if the counter logic leads to decisions based on stale data, although the primary failure mode here is logical inconsistency rather than uninitialized memory access. In terms of MITRE ATT&CK mapping, this vulnerability could be leveraged in techniques related to Defense Evasion or Privilege Escalation by exploiting race conditions between TLB invalidations and VNCR mappings to bypass expected isolation boundaries between virtual machines.
Mitigation strategies for organizations running affected versions of the Linux kernel involve applying upstream patches that remove the problematic counter logic from the KVM arm64 implementation. Administrators should ensure their systems are updated with the latest stable kernel releases where this fix is integrated. Additionally, monitoring for unusual guest behavior or hypervisor instability may help identify instances where this vulnerability might have been exploited in environments running unpatched kernels. Regular security audits focusing on virtualization layer integrity and adherence to strict memory management protocols can further reduce exposure to such low-level concurrency flaws.