GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel KVM nSVM: interrupt shadow not synced to cached vmcb12, nested vCPU can hang

CVSS 5.5CVE-2026-45987Kernel, userspace & hypervisorcurated

Impact

After a nested VMRUN on AMD hosts, KVM syncs CPU-written vmcb02 fields back to the cached vmcb12, but not int_state bit 0 (the interrupt shadow). If a restore path issues KVM_SET_VCPU_EVENTS before KVM_SET_NESTED_STATE, the interrupt shadow lands in vmcb01 instead of vmcb02. For L1 this only delays an interrupt; for an L2 guest the vCPU can hang outright - for example when a wakeup interrupt is delivered ahead of a HLT that should have been shadowed. The practical exposure is save/restore and live migration of nested guests on AMD GPU hosts: a nested workload can come back from migration permanently stuck, and the operator sees a hung vCPU rather than a clean failure. There is no indication in the record of a host-side memory-safety or escape consequence.

Who can reach it

Local, and only on AMD hosts with nested virtualization in use. Requires the ability to drive the vCPU save/restore ioctls (KVM_SET_VCPU_EVENTS, KVM_SET_NESTED_STATE) - i.e. the VMM process on the host, not a tenant inside the guest. Not reachable if nested virt is not exposed to tenants.

What to do

Update the host kernel to a stable release containing the fix and reboot each affected hypervisor node; live-migrating nested guests off first avoids reintroducing the stuck state. As an interim mitigation, do not expose nested virtualization to tenants and avoid save/restore of nested guests on unpatched hosts.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.