[PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS

[Jamie Nguyen]

> On May 13, 2026, at 10:15 AM, Sudeep Holla <sudeep.holla at kernel.org> wrote:
> 
> On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
>> __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 -EPROTO if the SPMC
>> reports something we can't safely walk.
>> 
> 
> Can you check if the issue is addressed in -next by:
> Commit 3974ea193840 ("firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies")

Thanks for the pointer.  I tested 3974ea193840 on the same hardware
that reproduces the bug, but the descriptor-stride issue is still
present.

The relevant loop at the end of __ffa_partition_info_get_regs()
still has:

	buf_sz = PARTITION_INFO_SZ(partition_info.a2);
	if (buf_sz > sizeof(*buffer))
		buf_sz = sizeof(*buffer);
	...
	for (idx = 0; idx < nr_desc; idx++, buf++) {
		...
		regs += 3;  /* bug is here */
	}

With 48-byte descriptors the SPMC returns nr_desc = 2 per call,
which passes the new MAX_DESC = 5 bound, and the loop then runs
the 24-byte stride over 48-byte entries.

Here are the test results on the same SBIOS / same hardware:

  unpatched:               5 partitions enumerated, two with
                           garbled UUIDs and partition_ids
  3974ea193840 alone:      same misparsed enumeration
  3974ea193840 + my patch: 6 partitions, all entries correct

So the two fixes look complementary rather than overlapping.

> -- 
> Regards,
> Sudeep