Date: Wed, 23 Sep 2026 10:16:11 -0700
In-Reply-To: <20260923165304.1662E1F000FF@smtp.kernel.org>
Precedence: bulk
Mime-Version: 1.0
References: <20260923163721.1584779-1-seanjc@google.com> <20260923163721.1584779-3-seanjc@google.com>
 <20260923165304.1662E1F000FF@smtp.kernel.org>
Message-ID: <arQJW6bs7RRjLJFv@google.com>
Subject: Re: [PATCH 2/2] KVM: SEV: Do cache maintenance on the source VM
 during intra-host migration
From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org
Content-Type: text/plain; charset="us-ascii"

On Wed, Sep 23, 2026, sashiko-bot@kernel.org wrote:
> 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?

Oof, yeah.  It's a tiny window, but also trivial to fix and document.