Re: [PATCH v15 09/20] unwind_user/sframe: Add support for outermost frame indication

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The size calculation for SFrame FRE evaluates to just the header size, incorrectly omitting the size of the datawords because it uses the mutated `dataword_count` variable.
--

commit a8be8d2031245c57fdb06e0cafc371dc3614077c
Author: Jens Remus <jremus@linux.ibm.com>

unwind_user/sframe: Add support for outermost frame indication

This commit adds support for the SFrame outermost frame indication. It
allows an FRE without any offsets to represent an undefined return
address.

> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> index a38f50a363633..f723c1a32f906 100644
> --- a/kernel/unwind/sframe.c
> +++ b/kernel/unwind/sframe.c

[ ... ]

> @@ -260,6 +271,7 @@ static __always_inline int __read_fre(struct sframe_section *sec,
>  	if (dataword_count)
>  		return -EINVAL;
>  
> +done:
>  	fre->size	= addr_size + 1 + (dataword_count * dataword_size);

[Severity: High]
This is a pre-existing issue, but does this calculation correctly size the FRE?

In __read_fre(), dataword_count is progressively decremented as offsets are
parsed, and it is guaranteed to be 0 at this point due to the check right
above the done label:

    if (dataword_count)
        return -EINVAL;

done:
    fre->size = addr_size + 1 + (dataword_count * dataword_size);

Because dataword_count is 0, fre->size evaluates to just the header size,
completely omitting the size of the datawords.

When __find_fre() executes fre_addr += fre->size, it advances the pointer by
this truncated amount. This would cause subsequent iterations to read
misaligned data and potentially break stack unwinding.

I see this was fixed later in the series in commit 9c045164b82cb
("unwind_user/sframe: Separate reading of FRE from reading of FRE data words"),
but noting it here for completeness.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260520154004.3845823-1-jremus@linux.ibm.com?part=9