Re: [PATCH v4 01/18] KVM: SEV: Track the GPA of the guest-controlled VMSA used for SNP guests

[Sean Christopherson <seanjc@google.com>]

On Thu, Jul 09, 2026, sashiko-bot@kernel.org wrote:
> > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > index 74fb15551e83f..827f5dc061023 100644
> > --- a/arch/x86/kvm/svm/sev.c
> > +++ b/arch/x86/kvm/svm/sev.c
> [ ... ]
> > @@ -4039,6 +4040,7 @@ static void sev_snp_init_protected_guest_state(struct kvm_vcpu *vcpu)
> >  	svm->sev_es.snp_has_guest_vmsa = true;
> >  
> >  	/* Use the new VMSA */
> > +	svm->sev_es.snp_guest_vmsa_gpa = gfn_to_gpa(gfn);
> >  	svm->vmcb->control.vmsa_pa = pfn_to_hpa(pfn);
> 
> [Severity: Critical]
> This is a pre-existing issue, but does this bypass the MMU invalidation retry
> protocol?
> 
> Looking at sev_snp_init_protected_guest_state(), KVM resolves the PFN via
> kvm_gmem_get_pfn(), directly installs it into the hardware VMCB, and drops
> the page reference:
> 
> 	if (kvm_gmem_get_pfn(vcpu->kvm, slot, gfn, &pfn, &page, NULL))
> 		return;
> 	...
> 	svm->vmcb->control.vmsa_pa = pfn_to_hpa(pfn);
> 	...
> 	kvm_release_page_clean(page);
> 
> Can this race with a concurrent guest_memfd hole punch if kvm->mmu_lock isn't
> held and the invalidation sequence counter isn't verified?
> 
> If the page is freed back to the host allocator, could the hardware continue
> to use a freed host physical page for the VMSA, leading to a physical
> use-after-free?

Read the cover letter?