CVE-2026-45987

What it actually does

This is a Linux KVM vulnerability in AMD SVM nested virtualization state handling. When restoring nested guest state, KVM failed to synchronize the SVM interrupt-shadow bit from the active nested VMCB to the cached nested VMCB. If KVM_SET_VCPU_EVENTS is applied before KVM_SET_NESTED_STATE, the interrupt-shadow state can be restored to the wrong virtualization control block. The result is that an L2 nested guest vCPU can miss or mishandle an interrupt around HLT/wakeup behavior and hang. The impact is availability loss for affected nested virtual machines; the issue does not provide confidentiality or integrity impact and does not imply host code execution.

Why it matters to the business

Organizations using Linux KVM with AMD nested virtualization may experience guest workload hangs or denial of service if an authenticated local user, VM manager, or tenant with KVM access triggers the vulnerable state-restoration path. The risk is most relevant to virtualization platforms, CI systems, developer workstations, hosting providers, and cloud environments that expose nested virtualization. The CVSS score indicates moderate severity with high availability impact, EPSS is currently very low, it is not listed in CISA KEV, and no public exploit maturity is reported, but affected systems should still be patched during normal kernel maintenance because exploitation can disrupt workloads that depend on nested VMs.

How an attack unfolds

An attacker first needs local privileges sufficient to interact with KVM, typically access to /dev/kvm or control of a VM/runtime that can create and manage nested AMD SVM guests. The attacker enables or uses nested virtualization, runs an L2 guest, and drives the vCPU through a state where an interrupt shadow exists around a halt or wakeup sequence. The attacker or malicious VM manager then causes nested vCPU state to be saved and restored in the problematic order, with KVM_SET_VCPU_EVENTS occurring before KVM_SET_NESTED_STATE. Because vulnerable kernels do not copy the CPU-written interrupt-shadow state into the cached nested VMCB, KVM restores the state to the wrong VMCB. The L2 vCPU may then fail to receive or process the intended wakeup interrupt and can hang, causing denial of service for that nested guest workload.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the KVM nSVM fix for synchronizing int_state to the cached vmcb12 in nested_sync_control_from_vmcb02(). Use the fixed kernel packages supplied by the relevant Linux distribution or appliance vendor; no exact fixed versions were provided in the input. After installing the update, reboot into the patched kernel or apply an approved live patch if the vendor supports one and confirms coverage for this issue. If immediate patching is not possible, reduce exposure by disabling AMD KVM nested virtualization, for example by setting the kvm_amd nested parameter to 0, and by restricting access to /dev/kvm to only trusted administrators and services. Consider moving untrusted nested virtualization workloads to patched hosts or hosts where nested virtualization is disabled until remediation is complete.

How to confirm the fix worked

Confirm the running kernel is the updated vendor kernel, not only that the package is installed, by checking the active kernel version after reboot. Verify that the vendor advisory or changelog for the installed kernel includes the KVM nSVM nested interrupt-shadow fix. Check whether nested virtualization remains enabled with module parameters such as /sys/module/kvm_amd/parameters/nested; if nested virtualization is intentionally disabled as a mitigation, confirm the value reflects that policy. Validate that only approved users and service accounts can access /dev/kvm. In a test environment, run nested AMD KVM workloads through save/restore, suspend/resume, migration, or vCPU event restore paths and confirm L2 vCPUs no longer hang under interrupt/HLT wakeup scenarios.

Typical attack path

1. Gain local authenticated access to a Linux host or VM runtime with permission to use KVM, such as membership in a group that can open /dev/kvm.
2. Confirm the host uses AMD SVM and has KVM nested virtualization enabled.
3. Create or control a nested virtualization workload with an L1 guest running an L2 guest.
4. Manipulate vCPU save/restore or migration-like flows so KVM_SET_VCPU_EVENTS is issued before KVM_SET_NESTED_STATE while interrupt-shadow state is relevant.
5. Trigger interrupt and HLT/wakeup timing in the nested guest so the stale or misplaced interrupt-shadow state affects L2 execution.
6. Cause the L2 vCPU to hang, degrading or denying availability of the nested VM workload.

How to detect it

Look for evidence of attempted or successful denial of service against nested KVM workloads rather than remote compromise. Useful log sources include systemd journal, kernel logs, hypervisor management logs, libvirt logs, QEMU process logs, auditd records for /dev/kvm access, and any EDR telemetry that records ioctl activity. Focus on AMD KVM hosts with nested virtualization enabled. Investigate repeated L2 guest hangs, vCPU stalls, unexplained nested VM pauses, watchdog or soft-lockup messages, and guest workloads that stop progressing after save/restore, suspend/resume, migration, snapshot restore, or vCPU event restoration. If audit or tracing was enabled, search for processes issuing KVM_SET_VCPU_EVENTS and KVM_SET_NESTED_STATE in close sequence, particularly if performed by unexpected users or nonstandard VM management processes. Absence of these artifacts does not rule out exploitation because default Linux logging usually does not record individual KVM ioctls.

• /dev/kvm
• KVM_SET_VCPU_EVENTS
• KVM_SET_NESTED_STATE
• kvm_amd
• nested=1
• /sys/module/kvm_amd/parameters/nested
• KVM: nSVM
• watchdog: BUG: soft lockup
• NMI watchdog: Watchdog detected hard LOCKUP
• rcu: INFO: rcu_sched self-detected stall
• qemu-system-x86_64
• libvirtd
• virtqemud

What your security team should do

• Prioritize patching Linux KVM hosts that run AMD processors and allow nested virtualization, especially shared virtualization platforms and CI/build systems running untrusted workloads.
• If patching must be delayed, disable nested virtualization for kvm_amd and migrate sensitive or untrusted nested workloads away from affected hosts.
• Restrict /dev/kvm access to trusted administrators and approved virtualization services; remove broad user or developer access where not required.
• Review virtualization management, audit, and system logs for unusual nested VM hangs, repeated vCPU resets, or concentrated use of KVM nested-state ioctls by untrusted processes.
• Track vendor kernel advisories for the exact fixed package versions applicable to each Linux distribution in use and verify hosts are rebooted into the fixed kernel.
• Because this issue is not in KEV, has very low EPSS, and has no reported public exploit maturity, handle it as a targeted availability risk rather than an emergency internet-scale exploitation event.