AMD KVM nested-virt bug corrupted host memory on live migration

A memory-corruption bug in Linux 6.18.x let live migration of certain Windows guests trash host RAM on AMD KVM servers, crashing VMs and host processes alike. The flaw is fixed in newer kernels and is headed for the 6.18 stable series after production bisecting pinned it down.

Nikola Ciprich reported the trouble on AlmaLinux 9 KVM hosts with AMD EPYC CPUs after upgrading from 5.15. Dynamic libraries appeared corrupted in memory (files on disk were fine), guests died mid-migration, and hosts sometimes panicked from kernel-structure damage. The pattern only showed up under load and resisted early guesses about drivers, transparent huge pages, and NUMA balancing.

The missing trigger was nested virtualization. Newer Windows guests enable Virtualization-Based Security (VBS), which runs a nested hypervisor. On AMD SVM that path exercises VMLOAD/VMSAVE handling. A mismatch while recalculating instruction intercepts could leave those operations neither intercepted nor properly virtualized, so a guest-supplied physical address could write straight into host memory. Corruption signatures matched AMD VMCB state appearing in unrelated host pages.

Yosry Ahmed had already fixed the intercept-recalculation mistake in mainline after code inspection, calling the bug benign because the usual L1 startup path masked it. Live migration of an L2 guest exposes the hole. Ciprich confirmed the patch: unpatched 6.18.56 crashed within a few VBS guest migrations and left host systemd libraries faulting; the same kernel with the fix survived 500-plus migrations cleanly. Newer release candidates were already solid.

Ahmed is repackaging the change with an accurate impact description so stable maintainers and downstream distros treat it as the serious migration hazard it is, not a harmless cleanup. Operators running Windows VBS workloads on AMD KVM under 6.18 should watch for the backport.