Re: [PATCH v16 02/20] unwind_user/sframe: Add support for reading .sframe headers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calculations for sframe section boundaries lack overflow checks, allowing malformed headers to bypass bounds validation on 32-bit architectures.
--

commit 054ec0b1d4b6a41d4be90015daaf62a201f3ec3b
Author: Josh Poimboeuf <jpoimboe@kernel.org>

unwind_user/sframe: Add support for reading .sframe headers

This commit introduces basic infrastructure for unwinding user space stacks
with sframe. It adds functionality to read and validate the .sframe section
header from user memory.

Link: https://lore.kernel.org/all/f27e8463783febfa0dabb0432a3dd6be8ad98412.1737511963.git.jpoimboe@kernel.org/

> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> new file mode 100644
> index 0000000000000..d24e9d4f8bef7
> --- /dev/null
> +++ b/kernel/unwind/sframe.c
> @@ -0,0 +1,136 @@
[ ... ]
> +static int sframe_read_header(struct sframe_section *sec)
> +{
> +	unsigned long header_end, fdes_start, fdes_end, fres_start, fres_end;
> +	struct sframe_header shdr;
> +	unsigned int num_fdes;
[ ... ]
> +	num_fdes   = shdr.num_fdes;
> +	fdes_start = header_end + shdr.fdes_off;
> +	fdes_end   = fdes_start + (num_fdes * sizeof(struct sframe_fde_v3));
> +
> +	fres_start = header_end + shdr.fres_off;
> +	fres_end   = fres_start + shdr.fre_len;

[Severity: High]
Could this introduce a regression on 32-bit architectures where these
boundary calculations overflow?

On 32-bit systems, operations like header_end + shdr.fdes_off and
num_fdes * sizeof(struct sframe_fde_v3) can overflow and wrap around to
small values. For example, if a malformed header sets num_fdes = 0x10000000,
the multiplication by 16 evaluates to 0.

This might allow a crafted sframe header to satisfy the subsequent
fres_start < fdes_end and fres_end <= sec->sframe_end checks, storing a
deceptively large num_fdes and out-of-bounds section pointers. When the kernel
unwinder later processes this section, it could attempt to iterate over
millions of entries or read from wrapped addresses, potentially causing CPU
stalls or soft lockups.

Could safe math helpers like check_add_overflow() or size_mul() be used
here to prevent silent wrap-arounds?

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