Linux kernel KVM nSVM: failed host CR3 restore on nested #VMEXIT keeps running L1 with corrupted state

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

Impact

If loading L1's CR3 fails during a nested #VMEXIT, nested_svm_vmexit() returned an error code that most callers ignored and KVM kept running L1 with corrupted state. AMD's APM says hardware shuts down in this case; KVM instead continued, so the guest hypervisor runs on state the architecture does not define. The fix injects a triple fault and finishes cleaning up the vCPU. This only matters on AMD hosts that actually run nested virtualization - a guest that is itself a hypervisor. On a GPU node that is normally a single level of virt or bare metal, there is no exposure; where nested virt is in use, the blast radius is that VM, not the host.

Who can reach it

Local to the host, from inside a guest: requires an AMD host with nested SVM enabled and a VM running its own guests. No host authentication is involved, but a tenant with only a plain VM or GPU pod cannot reach this path.

What to do

Take the stable kernel fix (commits linked from the NVD record), which drops the unchecked return value and injects a triple fault instead. Rollout is a kernel upgrade plus a reboot of the hypervisor host, which means evacuating or draining its VMs first. The record names no fixed release version. If you do not run nested virtualization on AMD hosts, disabling nested SVM removes the exposure without a maintenance window.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-46032 https://git.kernel.org/stable/c/2e661773890e6ba6b16064fad961da3dd311be43 https://git.kernel.org/stable/c/5d291ef0585ed880ed4dd71ea1a5965e0a65fb53

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.