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

[Sudeep Holla]

On Wed, May 13, 2026 at 07:48:05PM +0000, Jamie Nguyen wrote:
> 
> 
> > 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,

Well why is the firmware sending 48byte entry when 24byte is expected.

-- 
Regards,
Sudeep