[PATCH] KVM: arm64: Check the untrusted offset in FF-A memory share

[Will Deacon]

On Wed, Oct 29, 2025 at 10:27:27AM +0000, Sebastian Ene wrote:
> On Wed, Oct 22, 2025 at 04:21:41PM +0100, Vincent Donnefort wrote:
> > On Fri, Oct 17, 2025 at 07:57:10AM +0000, Sebastian Ene wrote:
> > > Verify the offset to prevent OOB access in the hypervisor
> > 
> > I believe that would be just a read, so probably it would be difficult to use
> > this to compromise anything, except crashing the system?
> 
> The simplest way is to crash the system but a more advanced one might
> lead to a confused deputy attack:
> 
> 1. Use the original bug to trigger the overflow of the offset variable
> which bypasses this check:
> https://elixir.bootlin.com/linux/v6.18-rc2/source/arch/arm64/kvm/hyp/nvhe/ffa.c#L519
> 
> 2. Use the host_share_hyp from the host to create a mapping in the hyp
> address space so that : reg from reg = (void *)buf + offset; points to
> memory mapped in the hyp address space & controlled from the host.
> 
> 3. Make the __ffa_host_share_ranges fail (since we control the content of
> the reg) to trigger the recovery mechanism for __ffa_host_unshare_ranges
> (https://elixir.bootlin.com/linux/v6.18-rc2/source/arch/arm64/kvm/hyp/nvhe/ffa.c#L392)
> and replace the content of the reg with pages that we want to remove the
> host stage-2 FF-A annotation from.
> 
> With step(3) we can remove the host stage-2 FF-A annotation from pages
> without having to invoke the FF-A reclaim mechanism. This allows a
> confused deputy attack because the pages can be given to another entity
> after the annotation is removed (eg. given to a protected VM).

Crikey, it's convoluted but I think your reasoning is correct and I also
think that the patch fixes the issue:

Acked-by: Will Deacon <will at kernel.org>

Cheers,

Will