CVE-2026-98863: KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Re-pend GETNESTEDSTATEPAGES if getting said pages fails
Re-pend GETNESTEDSTATEPAGES before exiting to userspace if getting the nested pages fails in the KVMRUN 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 KVMREQGETNESTEDSTATEPAGES 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue affects Linux kernel KVM on x86 when nested virtualization is in use. The described stale-PFN condition involves re-entering an L2 guest after retrieval of nested-state pages fails.
What conditions are needed to trigger the stale mapping scenario?
Getting nested-state pages must fail during the KVM_RUN path, userspace must then run the vCPU again, and vmcs02 must retain valid PFNs from a previous L2 run. Under those conditions, KVM could re-enter L2 with stale, unpinned PFNs, for example in the vAPIC page mapping.
Is there a described risk of double-mapping from emulated nested-virtualization instructions?
No. The data states that both SVM and VMX clear the GET_NESTED_STATE_PAGES request on VM-Exit, including forced exits, preventing double-mapping through emulated VMLAUNCH, VMRESUME, or VMRUN combined with the request.
What does the fix change?
The fix re-pends GET_NESTED_STATE_PAGES before KVM exits to userspace when obtaining the nested pages fails. This ensures the nested pages are requested again before a subsequent vCPU run.