Re: [PATCH] KVM: SEV: Don't return a still-assigned gmem page to the host

[Sean Christopherson <seanjc@google.com>]

On Thu, Jun 11, 2026, Michael Roth wrote:
> On Thu, Jun 11, 2026 at 08:23:00AM -0700, Sean Christopherson wrote:
> > On Thu, Jun 11, 2026, Hyunwoo Kim wrote:
> > > and if that gfn is then hole-punched, a page that is still assigned to the
> > > guest is returned to the host in sev_gmem_invalidate(), which looked like it
> > > could lead to a host RMP PF, so I sent the patch.
> > 
> > Yeah, I suspect you're right.  But leaking the page doesn't fix the underlying
> > problem, which is that it's possible to free a page that's being used as a VMSA.
> > 
> > We can't simply pin the page, because IIUC ->free_folio() is called when the page
> > is removed from the filemap, not when the folio/page is free back to the allocator.
> 
> If free_folio() triggers, it would call into the
> kvm_gmem_invalidate()/rmp_make_shared() path and clear VMSA bit, which I
> think would cause a subsequent vcpu_run() to error cleanly. So that part
> maybe isn't the issue, so much as the stale VMSA reference we have once
> the hole-punched finished at folio actually gets freed to allocator..

What if the vCPU that's associated with the VMSA is actively running?  I assume
trying to reclaim a VMSA page will fail with FAIL_INUSE or FAIL_PERMISSION;
that's the scenario I'm worried about.

> But KVM would never be accessing it directly while it's allocated for a
> vCPU (it would be garbage on the host-side anyway), and I think the CPU
> should only be able to write to it as part of VMRUN/exit, but those
> should immediately fail since it's not a VMSA page any more at that
> point.
> 
> It's sort of a precarious state, but I think we might hold up okay
> there.. so I'm not sure we actually need the changes below, unless I'm
> missing something.
> 
> ..but on the VM cleanup side, we'd end up doing a double-free in that
> case, so we would need still need the elevated reference to handle that.

I don't think so?  KVM doesn't free vmcb->control.vmsa_pa when tearing down the
vCPU, KVM only explicitly frees svm->sev_es.vmsa.