Re: [PATCH v2 7/8] KVM: s390: Lock pte when making page secure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Unconditional conversion of a raw PFN to a folio using `pfn_folio()` in `_kvm_s390_pv_make_secure()` leads to a host kernel panic when applied to device memory.
--

commit e0fa339799f284890bdbcc3dd174cd7125deb24a
Author: Claudio Imbrenda <imbrenda@linux.ibm.com>

KVM: s390: Lock pte when making page secure

This commit ensures that _kvm_s390_pv_make_secure() takes the pte lock
for the given address before freezing the folio during Secure Execution
transitions. This prevents concurrent GUP access while the page is mapped.

> diff --git a/arch/s390/kvm/pv.c b/arch/s390/kvm/pv.c
> index c2dafd812a3b2..4b865e75351c1 100644
> --- a/arch/s390/kvm/pv.c
> +++ b/arch/s390/kvm/pv.c
[ ... ]
> @@ -103,9 +105,21 @@ static void _kvm_s390_pv_make_secure(struct guest_fault *f)
>  {
>  	struct pv_make_secure *priv = f->priv;
>  	struct folio *folio;
> +	spinlock_t *ptl;	/* pte lock from try_get_locked_pte() */
> +	pte_t *ptep;
>  
>  	folio = pfn_folio(f->pfn);

[Severity: Critical]
This is a pre-existing issue, but can this unconditional conversion of a raw
PFN to a folio cause a host kernel panic when a guest maps device memory?

If a malicious or misconfigured guest maps device memory (e.g., via VFIO PCI)
into its address space and attempts to transition it to Secure Execution,
KVM's fault-in logic will return a valid PFN but set f->page = NULL for raw
device memory without a vmemmap.

If we unconditionally call pfn_folio(f->pfn) before checking f->page,
pfn_to_page() yields an invalid pointer. The page_folio() wrapper then
immediately dereferences this pointer to read the compound_head field.

Furthermore, even if the PFN is valid but points to a reserved page, the
fallback logic in __kvm_s390_pv_make_secure() could attempt to increment
the refcount of a reserved page:

__kvm_s390_pv_make_secure() {
    ...
    if (!f->page)
        folio_get(folio);
    ...
}

Could this crash the kernel via VM_BUG_ON_FOLIO() on systems with
CONFIG_DEBUG_VM enabled? Should the folio conversion be delayed until
after verifying we have a normal refcounted memory page?

>  	priv->rc = -EAGAIN;
> +
> +	if (!mmap_read_trylock(priv->kvm->mm))
> +		return;
> +
> +	ptep = try_get_locked_pte(priv->kvm->mm, gfn_to_hva(priv->kvm, f->gfn), &ptl);
> +	if (IS_ERR_VALUE(ptep)) {
> +		priv->rc = PTR_ERR(ptep);
> +		goto out;
> +	}
> +
>  	if (folio_trylock(folio)) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601152951.196859-1-imbrenda@linux.ibm.com?part=7