CVE-2026-45987: KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Sync interrupt shadow to cached vmcb12 after VMRUN of L2
After VMRUN in guest mode, nested_sync_control_from_vmcb02() syncs
fields written by the CPU from vmcb02 to the cached vmcb12. This is
because the cached vmcb12 is used as the authoritative copy of some of
the controls, and is the payload when saving/restoring nested state.
int_state is also written by the CPU, specifically bit 0 (i.e.
SVM_INTERRUPT_SHADOW_MASK) for nested VMs, but it is not sync'd to
cached vmcb12. This does not cause a problem if KVM_SET_NESTED_STATE
preceeds KVM_SET_VCPU_EVENTS in the restore path, as an interrupt shadow
would be correctly restored to vmcb02 (KVM_SET_VCPU_EVENTS overwrites
what KVM_SET_NESTED_STATE restored in int_state).
However, if KVM_SET_VCPU_EVENTS preceeds KVM_SET_NESTED_STATE, an
interrupt shadow would be restored into vmcb01 instead of vmcb02. This
would mostly be benign for L1 (delays an interrupt), but not for L2. For
L2, the vCPU could hang (e.g. if a wakeup interrupt is delivered before
a HLT that should have been in an interrupt shadow).
Sync int_state to the cached vmcb12 in nested_sync_control_from_vmcb02()
to avoid this problem. With that, KVM_SET_NESTED_STATE restores the
correct interrupt shadow state, and if KVM_SET_VCPU_EVENTS follows it
would overwrite it with the same value.
Security readout for executives and security teams
Plain-English summary
This Linux KVM flaw can leave a nested virtual machine in the wrong interrupt state after restore. The documented outcome is an L2 vCPU hang, so the main business risk is availability disruption for environments running nested virtualization, not data theft or code execution based on the supplied sources.
Executive priority
Treat as a targeted availability issue for virtualization platforms. Patch during the next appropriate maintenance cycle, faster for infrastructure that depends on nested virtualization or customer-facing lab, CI, cloud, or security testing workloads.
Technical view
In KVM nSVM, CPU-written int_state bit 0 was not synchronized from vmcb02 to cached vmcb12 after L2 VMRUN. If KVM_SET_VCPU_EVENTS happens before KVM_SET_NESTED_STATE during restore, interrupt shadow may be restored to vmcb01 instead of vmcb02, potentially hanging the L2 vCPU.
Likely exposure
Exposure appears limited to Linux KVM hosts using AMD SVM nested virtualization with affected kernels. Organizations not running nested guests are less likely to be impacted. The source lists affected Linux kernel version entries but does not provide distribution-specific package names.
Exploitation context
The supplied sources do not show active exploitation, public weaponization, or KEV listing. The described trigger relates to nested VM state restore ordering and can cause an L2 vCPU hang. Evidence supports an availability impact, not privilege escalation or remote code execution.
Researcher notes
The core defect is stale nested SVM interrupt shadow state in cached vmcb12. The CVE description gives a concrete failure mode but no CVSS, CWE, exploit status, or distribution package mapping. Research should stay focused on affected KVM nSVM restore paths and vendor backports.
Mitigation direction
Update affected Linux kernels using vendor packages that include the referenced stable fixes.
Prioritize KVM hosts running nested virtualization on AMD SVM hardware.
Confirm your distribution has backported the fix for its supported kernel build.
Where patching is delayed, check vendor guidance for supported temporary controls.
Schedule guest migration or host reboot as required by your kernel update process.
Validation and detection
Inventory Linux KVM hosts that run nested virtualization workloads.
Check running kernel builds against vendor advisories and the referenced stable commits.
Identify workloads that save or restore nested VM state.
Test nested guest restore behavior in staging after applying the kernel update.
Monitor affected hosts for nested guest vCPU hangs until remediation is complete.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-45987 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
0CVSS vectors
3Timeline events
0ADP providers
9Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 27, 2026, 12:55 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.