From: Sebastian Ene <sebastianene@google.com>
To: Vincent Donnefort <vdonnefort@google.com>
Cc: maz@kernel.org, oliver.upton@linux.dev, will@kernel.org,
catalin.marinas@arm.com, suzuki.poulose@arm.com,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, joey.gouly@arm.com,
ayrton@google.com, yuzenghui@huawei.com, qperret@google.com,
kernel-team@android.com
Subject: Re: [PATCH] KVM: arm64: Check the untrusted offset in FF-A memory share
Date: Wed, 29 Oct 2025 10:27:27 +0000 [thread overview]
Message-ID: <aQHsD0MnZYSTDOf8@google.com> (raw)
In-Reply-To: <aPj2hTXbGUseUqhE@google.com>
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).
>
> > FF-A buffer in case an untrusted large enough value
> > [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX]
> > is set from the host kernel.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > arch/arm64/kvm/hyp/nvhe/ffa.c | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > index 4e16f9b96f63..58b7d0c477d7 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > @@ -479,7 +479,7 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> > struct ffa_mem_region_attributes *ep_mem_access;
> > struct ffa_composite_mem_region *reg;
> > struct ffa_mem_region *buf;
> > - u32 offset, nr_ranges;
> > + u32 offset, nr_ranges, checked_offset;
> > int ret = 0;
> >
> > if (addr_mbz || npages_mbz || fraglen > len ||
> > @@ -516,7 +516,12 @@ static void __do_ffa_mem_xfer(const u64 func_id,
> > goto out_unlock;
> > }
> >
> > - if (fraglen < offset + sizeof(struct ffa_composite_mem_region)) {
> > + if (check_add_overflow(offset, sizeof(struct ffa_composite_mem_region), &checked_offset)) {
> > + ret = FFA_RET_INVALID_PARAMETERS;
> > + goto out_unlock;
> > + }
> > +
> > + if (fraglen < checked_offset) {
> > ret = FFA_RET_INVALID_PARAMETERS;
> > goto out_unlock;
> >
>
> Perhaps this could be easier to reason about by moving this check with the nr_ranges?
I found it a bit more clear to use the helper on the offset variable, I
would like to keep it in this way if you are ok with this.
>
> reg = (void *)buf + offset;
> if ((void *)reg->constituents > (void *)buf + fraglen) {
> ret = FFA_RET_INVALID_PARAMETERS;
> goto out_unlock;
> }
>
> nr_ranges = ((void *)buf + fraglen) - (void *)reg->constituents;
> if (nr_ranges % sizeof(reg->constituents[0])) {
> ret = FFA_RET_INVALID_PARAMETERS;
>
Thanks,
Sebastian
> }
> > --
> > 2.51.0.858.gf9c4a03a3a-goog
> >
next prev parent reply other threads:[~2025-10-29 10:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 7:57 [PATCH] KVM: arm64: Check the untrusted offset in FF-A memory share Sebastian Ene
2025-10-22 15:21 ` Vincent Donnefort
2025-10-29 10:27 ` Sebastian Ene [this message]
2025-10-29 16:23 ` Will Deacon
2025-10-30 16:23 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQHsD0MnZYSTDOf8@google.com \
--to=sebastianene@google.com \
--cc=ayrton@google.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=qperret@google.com \
--cc=suzuki.poulose@arm.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.