Re: [PATCH v8 5/6] KVM: arm64: Ensure FFA ranges are page aligned

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Host-controlled invalid handles in FFA_MEM_FRAG_TX trigger a fatal hypervisor panic via WARN_ON.
--

commit b0b1c44dd777f162d56e942a3bb04410af9b98a8
Author: Mostafa Saleh <smostafa@google.com>

    KVM: arm64: Ensure FFA ranges are page aligned
    
    Harden the check for the constituent memory region page alignment
    to prevent over-sharing when the negotiated FFA_PAGE_SIZE size is
    smaller than the system PAGE_SIZE.
    At the moment we only check that the size of the range is page
    aligned, and truncate the address to the page boundary which can
    annotate more memory than needed as being used by the FF-A.

> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 14aa37846059a..bb01d8f830561 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -352,7 +352,7 @@ static u32 __ffa_host_share_ranges(struct ffa_mem_region_addr_range *ranges,
>  		u64 sz = (u64)range->pg_cnt * FFA_PAGE_SIZE;
>  		u64 pfn = hyp_phys_to_pfn(range->address);
>  
> -		if (!PAGE_ALIGNED(sz))
> +		if (!PAGE_ALIGNED(sz | range->address))
>  			break;

[Severity: High]
This isn't a bug introduced by this patch, but I have a question about the
error handling when ffa_host_share_ranges() fails due to these alignment
checks.

If the host kernel issues an FFA_MEM_FRAG_TX SMC with a valid fraglen but an
invalid handle_lo or handle_hi, and a fragment whose descriptor contains an
unaligned address, ffa_host_share_ranges() will fail.

Looking at do_ffa_mem_frag_tx() in arch/arm64/kvm/hyp/nvhe/ffa.c:

do_ffa_mem_frag_tx() {
    ...
	ret = ffa_host_share_ranges(buf, nr_ranges);
	if (ret) {
		/*
		 * We're effectively aborting the transaction, so we need
		 * to restore the global state back to what it was prior to
		 * transmission of the first fragment.
		 */
		ffa_mem_reclaim(res, handle_lo, handle_hi, 0);
		WARN_ON(res->a0 != FFA_SUCCESS);
		goto out_unlock;
	}
    ...
}

Because the host provided a bogus handle, the SPMD firmware will reject this
reclaim and return an error (e.g., FFA_INVALID_PARAMETERS). Doesn't this cause
the WARN_ON() to fire, leading to a fatal hypervisor panic triggered by
untrusted host input?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260630102058.3219867-2-sebastianene@google.com?part=5