CVE-2026-98863
NoneCVSS
—
EPSS
0.2%
Published
Oct 18, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's handling of virtual machine memory pages could let a restarted virtual machine use outdated memory references, potentially causing crashes or instability in nested setups.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Moderate
- Impact
- Privilege Gain
- Component
- OS kernel
- Class
- Race Condition
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Failure to re-pend a nested state page request on error in the KVM_RUN path allows re-entry into L2 with stale unpinned PFNs mapped into structures such as the vAPIC page after a userspace re-run of the vCPU.
Why it matters to the business
Nested virtualization workloads on affected kernels may experience unexpected guest crashes, data corruption, or hypervisor instability when page acquisition fails and the vCPU is restarted, increasing operational risk for cloud and virtualization platforms until patched.
How an attack unfolds
An attacker with control of a nested guest or userspace component triggers a failure when KVM attempts to obtain nested state pages, then re-invokes KVM_RUN; because the request was not re-pended, KVM may re-enter L2 using previously valid but now invalid PFNs, leading to improper memory mappings.
How to fix it
Apply the upstream kernel commit that re-pends GET_NESTED_STATE_PAGES on failure before exiting to userspace; rebuild and deploy updated kernels across all hosts running KVM nested virtualization.
How to confirm the fix worked
Confirm the fix is present by inspecting the KVM x86 code for the re-pend logic after nested page acquisition failure, and test by injecting page-get failures followed by vCPU re-runs to verify the request remains pending.
Typical attack path
- Trigger a transient failure while KVM fetches nested state pages for L2
- Allow or force userspace to re-invoke KVM_RUN on the vCPU without clearing the request
- KVM re-enters L2 using stale PFNs previously mapped into the vAPIC or similar structures
How to detect it
Examine kernel logs for KVM nested state page acquisition failures followed by unexpected L2 re-entries or vCPU restarts; review dmesg and hypervisor audit logs for related page pinning or PFN mapping anomalies around the time of any guest instability.
What your security team should do
- Prioritize kernel updates on hosts that enable nested virtualization within the next maintenance window
- Monitor EPSS and KEV status for any increase in exploit maturity
- Review nested virtualization usage and disable where not required until patches are applied
The record
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.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|