Re: [PATCH v14 17/19] unwind_user/sframe: Separate reading of FRE from reading of FRE data words

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] A malicious user can trigger a kernel panic by providing a crafted `.sframe` section with `rep_size` set to 0, which causes a division-by-zero when the kernel attempts to unwind the stack.
--

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

unwind_user/sframe: Separate reading of FRE from reading of FRE data words

This commit separates the reading of SFrame FRE structures from their
data words, which allows linear searches to skip data words until a
matching FRE is found. New fields are added to struct sframe_fre_internal
to cache the necessary information to read data words later.

> diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c
> index 2ba2c8b385f96..98346412078b8 100644
> --- a/kernel/unwind/sframe.c
> +++ b/kernel/unwind/sframe.c

[ ... ]

> @@ -455,6 +450,7 @@ static __always_inline int __find_fre(struct sframe_section *sec,
>  	bool which = false;
>  	unsigned int i;
>  	u32 ip_off;
> +	int ret;
>  
>  	ip_off = ip - fde->func_addr;
>  

This isn't a regression introduced by this patch, but while looking at this
area, can a crafted sframe section cause a division-by-zero just after
this line?

In __find_fre(), the code does:

    if (fde_pctype == SFRAME_FDE_PCTYPE_MASK)
        ip_off %= fde->rep_size;

Since fde->rep_size and fde->info are populated directly from the user-provided
sframe section, does anything ensure rep_size is non-zero before reaching
this code?

If a user provides an sframe section with rep_size set to 0 and the
SFRAME_FDE_PCTYPE_MASK bit set in the info field, will this lead to an
unhandled division-by-zero exception and crash the kernel during stack
unwinding?

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