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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQI_essk_agEZTTR@willie-the-truck>
Date: Wed, 29 Oct 2025 16:23:22 +0000
From: Will Deacon <will@...nel.org>
To: Sebastian Ene <sebastianene@...gle.com>
Cc: Vincent Donnefort <vdonnefort@...gle.com>, maz@...nel.org,
	oliver.upton@...ux.dev, catalin.marinas@....com,
	suzuki.poulose@....com, kvmarm@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	joey.gouly@....com, ayrton@...gle.com, yuzenghui@...wei.com,
	qperret@...gle.com, kernel-team@...roid.com
Subject: Re: [PATCH] KVM: arm64: Check the untrusted offset in FF-A memory
 share

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@...nel.org>

Cheers,

Will