CVE-2026-98863 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails
Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path. If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page.
Note, both SVM and VMX (as of commit 11722439fb20 ("KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit") ensure the request is cleared on VM-Exit (including the "forced" case), i.e. there is no risk of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request trying to map the nested pages.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified in the Linux kernel's KVM subsystem relates to improper state management during nested virtualization operations, specifically concerning the handling of GET_NESTED_STATE_PAGES requests within the x86 architecture implementation. This issue arises when the hypervisor attempts to retrieve physical frame numbers (PFNs) for nested guest pages but encounters a failure condition that prevents successful mapping or pinning of these resources. In such scenarios, if the system does not properly re-queue or pend this request before exiting control back to userspace, it leaves the virtual CPU in an inconsistent state where subsequent execution attempts may proceed with invalid assumptions about memory availability and validity.
The core technical flaw lies in the KVM_RUN path logic, which governs how a virtual CPU is scheduled for execution. When retrieving nested state pages fails, typically due to resource constraints or mapping errors, the system must ensure that this operation is not silently dropped but rather marked as pending so it can be retried upon the next invocation of the vCPU. Without re-pending the GET_NESTED_STATE_PAGES request, the hypervisor may allow a subsequent run cycle to proceed under the assumption that necessary resources are available. This oversight creates a window where stale or unpinned PFNs from previous execution contexts remain mapped into critical structures such as the virtual Advanced Programmable Interrupt Controller (vAPIC) page. These stale mappings persist because the system failed to clear or reset the state associated with the failed operation, leading to potential data corruption or unauthorized access patterns within the nested guest environment.
The operational impact of this vulnerability is significant for environments utilizing nested virtualization features on both SVM and VMX architectures. If userspace re-runs a vCPU without properly handling the failure case, KVM may re-enter the L2 (nested guest) execution context using outdated physical frame numbers that no longer correspond to valid or secure memory regions. This can result in unpredictable behavior within the nested virtual machine, including potential crashes, data leakage between isolation boundaries, or exploitation of race conditions where stale mappings are accessed after they have been freed or repurposed by other system components. Although recent commits have addressed related issues regarding clearing requests on VM-Exit to prevent double-mapping during emulated launch and resume operations, the specific failure path in KVM_RUN remained unmitigated until this fix was applied.
From a security taxonomy perspective, this vulnerability aligns with CWE-362, which describes concurrent execution using shared resources with improper synchronization, as well as CWE-419 regarding uninitialized read vulnerabilities if stale data is interpreted as valid state. In the context of the MITRE ATT&CK framework for enterprise security, this type of flaw could potentially be leveraged in techniques related to virtual machine escape or privilege escalation within cloud infrastructure by exploiting inconsistencies in hypervisor memory management states. The lack of proper synchronization and state validation allows an attacker with control over userspace VM operations to manipulate the internal state of the KVM subsystem, thereby undermining the isolation guarantees provided by hardware-assisted virtualization extensions like Intel VT-x or AMD-V.
To mitigate this vulnerability, system administrators and developers must ensure that their Linux kernels are updated to include patches addressing the GET_NESTED_STATE_PAGES handling logic in the x86 KVM implementation. This involves applying kernel updates that enforce proper re-pending of state retrieval requests upon failure within the KVM_RUN path. Additionally, rigorous testing of nested virtualization workloads should be conducted to verify that error conditions during page mapping are correctly propagated and do not lead to stale memory mappings in subsequent execution cycles. Developers implementing custom hypervisor extensions or interacting with KVM ioctls must also ensure they handle return codes indicating resource acquisition failures appropriately, avoiding assumptions about the validity of previously mapped pages when operations fail mid-execution cycle.