All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Nguyen <jamien@nvidia.com>
To: <sudeep.holla@kernel.org>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <jamien@nvidia.com>
Subject: [PATCH v2] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
Date: Fri, 15 May 2026 10:44:32 -0700	[thread overview]
Message-ID: <20260515174432.13419-1-jamien@nvidia.com> (raw)
In-Reply-To: <20260515-quixotic-active-dragon-2ee2c6@sudeepholla>

__ffa_partition_info_get_regs() walks the response with a hardcoded
24-byte stride (regs += 3) even though the SPMC tells us the actual
per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
read into buf_sz and then thrown away.

That works while every SPMC returns the FF-A v1.1 layout, but it falls
apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
strides over half a descriptor at a time and ends up parsing every
other entry from a slice of two adjacent ones.

The FF-A spec (v1.2, section 18.5) says that the producer should
report the descriptor size, and the consumer is supposed to stride by
that size and ignore any trailing fields it doesn't understand. The
non-REGS path (__ffa_partition_info_get) does this already, and the
REGS path should match.

Use buf_sz for the stride, and bail out with -EINVAL if the SPMC
reports something we can't safely walk.

Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS")
Signed-off-by: Jamie Nguyen <jamien@nvidia.com>
---
Changes in v2:
- Rebase onto linux-next; reuse the
  FFA_PART_INFO_GET_REGS_{REGS_PER_DESC,MAX_DESC} macros it added instead of
  introducing new ones.
- Return -EINVAL instead of -EPROTO to match surrounding checks.
- Update Fixes: tag to the commit that introduced the hardcoded stride.
---
 drivers/firmware/arm_ffa/driver.c | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index b9f17fda7243..38ae4476e864 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -374,9 +374,23 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
 			return -EINVAL;
 
 		tag = UUID_INFO_TAG(partition_info.a2);
+
+		/*
+		 * Per FF-A v1.2 section 18.5 the SPMC reports the per-
+		 * descriptor size and consumers must stride by that size,
+		 * reading only the fields they understand and ignoring any
+		 * trailing ones. Reject sizes that cannot hold the v1.1
+		 * fields parsed below, are not u64-aligned, or whose total
+		 * payload would walk past the x3..x17 window (e.g. a v1.3
+		 * 48-byte descriptor with nr_desc > 2).
+		 */
 		buf_sz = PARTITION_INFO_SZ(partition_info.a2);
-		if (buf_sz > sizeof(*buffer))
-			buf_sz = sizeof(*buffer);
+		if (buf_sz < FFA_PART_INFO_GET_REGS_REGS_PER_DESC * sizeof(u64) ||
+		    buf_sz % sizeof(u64) ||
+		    nr_desc * (buf_sz / sizeof(u64)) >
+		    FFA_PART_INFO_GET_REGS_MAX_DESC *
+		    FFA_PART_INFO_GET_REGS_REGS_PER_DESC)
+			return -EINVAL;
 
 		regs = (void *)&partition_info.a3;
 		for (idx = 0; idx < nr_desc; idx++, buf++) {
@@ -395,7 +409,7 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
 			buf->exec_ctxt = PART_INFO_EXEC_CXT(val);
 			buf->properties = PART_INFO_PROPERTIES(val);
 			uuid_copy(&buf->uuid, &uuid_regs.uuid);
-			regs += 3;
+			regs += buf_sz / sizeof(u64);
 		}
 		start_idx = cur_idx + 1;
 

base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
-- 
2.34.1



      reply	other threads:[~2026-05-15 17:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13  3:28 [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS Jamie Nguyen
2026-05-13 17:15 ` Sudeep Holla
2026-05-13 19:48   ` Jamie Nguyen
2026-05-14  9:16     ` Sudeep Holla
2026-05-14 17:37       ` Jamie Nguyen
2026-05-15  9:23         ` Sudeep Holla
2026-05-14  9:31 ` Sudeep Holla
2026-05-14 17:37   ` Jamie Nguyen
2026-05-15  9:40     ` Sudeep Holla
2026-05-15 17:44       ` Jamie Nguyen [this message]

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=20260515174432.13419-1-jamien@nvidia.com \
    --to=jamien@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@kernel.org \
    /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.