KVM nested VMX teardown can corrupt unrelated process memory

KVM can corrupt memory belonging to an unrelated process when tearing down a virtual machine that used nested Intel VMX. The flaw surfaces because the process that owned the VM has often already exited by the time destruction runs, so the kernel thread performing teardown no longer has that process's address space as current. Any write that KVM still believes is going to guest memory can therefore land in whatever mappings happen to be present and writable in the current task.

Sean Christopherson posted a 23-patch series that closes the known paths and adds defense in depth. The immediate fix makes the common userspace-access helpers refuse the operation whenever the current mm does not match the VM's mm, turning a silent corruption into a clean failure. A second change stops nested VMX from abusing the architectural nested VM-exit path while a vCPU is being destroyed; that flow was the concrete source of the bad writes on x86.

Christopherson also reports that PowerPC KVM appears to ignore the arch hook that should flush shadow page tables when the owning process exits, leaving its mappings behind. The remaining patches install empty dummy memslots early in destruction, reject further memslot updates once the VM's reference count has dropped to zero, and warn on any attempt to touch guest memory after that point. The goal is to make rogue accesses during kvm_arch_destroy_vm fail noisily instead of writing into the wrong address space, even if a future arch path bypasses the normal uaccess helpers.

The first few fixes are marked for the current stable kernel; the broader hardening can wait. Nested VMX is the only confirmed trigger so far, but the series treats the teardown window as generally unsafe and closes it for every architecture.