Re: [PATCH 2/2] KVM: SEV: Do cache maintenance on the source VM during intra-host migration

[sashiko-bot@kernel.org]

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 <seanjc@google.com>

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.

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index c9242c936a401..71923cb72d1d1 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -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?

> +
>  	list_cut_before(&dst->regions_list, &src->regions_list, &src->regions_list);
>  
>  	mutex_lock(&sev_mirror_lock);

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923163721.1584779-1-seanjc@google.com?part=2