KVM: SEV: Fix intra-host migration cache bugs

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] kvm: double free of sev->have_run_cpus on initialization failure --

commit 35fcc7370ece167eff16a7738a6c47e4815c1ae4
Author: Sean Christopherson <[email protected]>

KVM: SEV: Free have_run_cpus during VM destruction even if VM is no longer SEV

Unconditionally free SEV's "have run CPUs" cpumask in the VM destroy path, i.e. even for what appear to be non-SEV VMs, as an SEV VM becomes a non-SEV VM if its state is intra-host migrated.

arch/x86/kvm/svm/sev.c void sev_vm_destroy(struct kvm *kvm) · line 2988

Quoted 13 lines

arch/x86/kvm/svm/sev.c +5 -0

index 63e8cfa9bf559..c9242c936a401 100644
@@ -2981,13 +2981,17 @@ void sev_vm_destroy(struct kvm *kvm)
 	struct list_head *head = &sev->regions_list;
 	struct list_head *pos, *q;
 
+	/*
+	 * Free the mask even if the VM is not *currently* an SEV VM, as it may
+	 * have been an SEV VM prior to intra-host migration.
+	 */
+	free_cpumask_var(sev->have_run_cpus);

[Severity: Critical]
Can this cause a double free of sev->have_run_cpus?

If a user issues a KVM_SEV_INIT ioctl and __sev_guest_init() fails after allocating the cpumask, the error path in __sev_guest_init() frees the mask but leaves the pointer intact:

arch/x86/kvm/svm/sev.c:__sev_guest_init() {
    ...
e_free:
	free_cpumask_var(sev->have_run_cpus);
    ...
}

Because free_cpumask_var() receives the mask by value, the pointer remains dangling. When the user later closes the VM file descriptor, kvm_destroy_vm() calls sev_vm_destroy().

Prior to this patch, the early return on !sev_guest(kvm) prevented the second free. By moving free_cpumask_var() before the !sev_guest(kvm) check, won't we unconditionally double free the dangling pointer?

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] kvm: sev: TOCTOU race in sev_migrate_from causes host memory corruption --

commit b97586a7411bd5d8a55967b35859f6e485f10868
Author: Sean Christopherson <[email protected]>

KVM: SEV: Do cache maintenance on the source VM during intra-host migration

This commit manually performs cache maintenance on the source VM during intra-host migration. Since the source VM is converted to a non-SEV VM, automatic memory reclaim flows will not trigger the required cache maintenance, potentially leaving stale data in the CPU caches.

arch/x86/kvm/svm/sev.c static void sev_migrate_from(struct kvm *dst_kvm, struct kvm *src_kvm) · line 2055

Quoted 13 lines

arch/x86/kvm/svm/sev.c +5 -0

index c9242c936a401..71923cb72d1d1 100644
@@ -2048,6 +2048,12 @@ static void sev_migrate_from(struct kvm *dst_kvm, struct kvm *src_kvm)
 	src->pages_locked = 0;
 	src->es_active = false;
 
+	/*
+	 * Do cache maintenance on the source VM as it is no longer an SEV VM,
+	 * i.e. memory reclaim flows won't trigger cache maintenance on the VM.
+	 */
+	sev_writeback_caches(src_kvm);

[Severity: Critical]
Is there a race condition here if memory is reclaimed concurrently?

If a userspace process or kernel reclaim triggers a memory unmap (for example, via MADV_DONTNEED) concurrently with the KVM ioctl, it could happen in the window between setting src->active to false and calling sev_writeback_caches():

CPU1 in sev_migrate_from():

    src->active = false;

CPU2 running concurrent unmap:
Since active is false, the automatic cache flush in sev_guest_memory_reclaimed is skipped.
The host frees and reallocates the page.

CPU1 in sev_migrate_from():
sev_writeback_caches(src_kvm);
Executes a hardware cache flush (wbnoinvd), which writes the guest's old dirty ciphertext over the new page owner's data.

Because sev_migrate_from runs without mmap_lock or mmu_lock, MMU notifiers can run concurrently. Can this cause host memory corruption by overwriting newly allocated host pages with stale ciphertext?