Re: [PATCH v7 4/7] KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Unbalanced double-release of the FF-A RX buffer on the newly added error path.
--

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

KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim()

This commit addresses a potential out-of-bounds access by splitting the FF-A
descriptor length validation into two steps. It ensures that both the fixed
portion and the variable array size (addr_range_cnt) fit within the
descriptor length.

> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 1af722771178a..2d211661952e3 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c

[ ... ]

> @@ -636,11 +636,17 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
>  		ffa_rx_release(res);
>  	}
>  
> +	reg = (void *)buf + offset;
> +	if (offset + CONSTITUENTS_OFFSET(reg->addr_range_cnt) > len) {
> +		ret = FFA_RET_ABORTED;
> +		ffa_rx_release(res);

[Severity: Low]
Does this error path trigger an unbalanced double-release of the FF-A RX
buffer?

Looking just above this new block, the EL2 RX buffer has already been
released prior to the loop and at the end of every fragment iteration:

	for (fragoff = fraglen; fragoff < len; fragoff += fraglen) {
		...
		memcpy((void *)buf + fragoff, hyp_buffers.rx, fraglen);
		ffa_rx_release(res);
	}

If the newly added bounds check fails here, calling ffa_rx_release() again
appears to issue a spurious FFA_RX_RELEASE SMC call to the SPMD for a buffer
KVM no longer holds. Would it be better to omit the ffa_rx_release() in
this new error path?

> +		goto out_unlock;
> +	}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260617145130.3729015-1-sebastianene@google.com?part=4