LiveActive security incident?Get immediate response
CVE Record

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.

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

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.
Prepared
Confidence
medium
Sources
10

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.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

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.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinuxcc440cdad5b7a4c1de12dace725209eb3e0cf663, cc440cdad5b7a4c1de12dace725209eb3e0cf663, cc440cdad5b7a4c1de12dace725209eb3e0cf663, cc440cdad5b7a4c1de12dace725209eb3e0cf663, cc440cdad5b7a4c1de12dace725209eb3e0cf663, cc440cdad5b7a4c1de12dace725209eb3e0cf663, cc440cdad5b7a4c1de12dace725209eb3e0cf663, cc440cdad5b7a4c1de12dace725209eb3e0cf663unaffected
LinuxLinux5.8, 0, 5.10.258, 5.15.209, 6.1.175, 6.6.140, 6.12.86, 6.18.27, 7.0.4, 7.1affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.