Re: [PATCH 5/7] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Deleting a guest_memfd-backed memslot severs invalidation callbacks but leaves the VMSA loaded in hardware, allowing the pages to be freed while in-use and crashing the host.
--

commit 1d8649cc04198822af1b4661735a4bc1d852fe1f
Author: Sean Christopherson <seanjc@google.com>

KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped

This commit wires up a gmem_invalidate_range() call for SNP VMs. It forces
vCPUs to reload or recheck their guest-provided VMSA if the backing
guest_memfd page is being invalidated.

Closes: https://lore.kernel.org/all/aimMWzAf5b3luM0b@v4bel

> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 1618acc3ca647..8ec5041934dbc 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -185,6 +185,10 @@ static void __kvm_gmem_invalidate_start(struct gmem_file *f, pgoff_t start,
>  		}
>  
>  		flush |= kvm_mmu_unmap_gfn_range(kvm, &gfn_range);
> +
> +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE
> +		kvm_arch_gmem_invalidate_range(kvm, &gfn_range);
> +#endif
>  	}
>  
>  	if (flush)

[Severity: Critical]
Does this invalidation path cover the case where the memslot is unbound before
the guest_memfd pages are freed?

If userspace deletes the memslot (e.g., via KVM_SET_USER_MEMORY_REGION2),
kvm_gmem_unbind() removes the slot from the f->bindings xarray.

If userspace then closes the guest_memfd file descriptor,
__kvm_gmem_invalidate_start() will iterate over f->bindings here, find it
empty, and skip calling kvm_arch_gmem_invalidate_range().

Since the vCPU is never kicked to reload the VMSA, the hardware could still be
actively using the page. When sev_gmem_free_folio() attempts to transition the
pages to shared via rmp_make_shared(), the hardware will reject it with
FAIL_INUSE.

Could this leak the encrypted page to the host allocator and subsequently
cause an RMP violation #PF?

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