Re: [PATCH v14 13/19] unwind_user: Enable archs that pass RA in a register

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unprivileged user space can trigger a kernel warning (`WARN_ON_ONCE`) and potential panic by providing a maliciously crafted `.sframe` section.
--

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

unwind_user: Enable archs that pass RA in a register

This commit updates the user space stack unwinder to support architectures
that pass the return address in a register instead of saving it on the
stack. It also handles architectures where the stack pointer may be
unchanged in the topmost frame.

> diff --git a/include/linux/unwind_user.h b/include/linux/unwind_user.h
> index 64618618febde..bc2edae399556 100644
> --- a/include/linux/unwind_user.h
> +++ b/include/linux/unwind_user.h
> @@ -23,6 +23,15 @@ static inline bool unwind_user_at_function_start(struct pt_regs *regs)
>  #define unwind_user_at_function_start unwind_user_at_function_start
>  #endif
>  
> +#ifndef unwind_user_get_ra_reg
> +static inline int unwind_user_get_ra_reg(unsigned long *val)
> +{
> +	WARN_ON_ONCE(1);

Can a maliciously crafted .sframe section trigger this warning and panic
the kernel if panic_on_warn is enabled?

The SFrame unwind data is parsed from user-provided ELF binaries, so the
.sframe sections are entirely user-controlled.

If an unprivileged user on an architecture using the generic fallback
provides an SFrame Frame Row Entry with dataword_count > 0 but an
explicit ra_off dataword of 0, it appears this would bypass the
frame->outermost check while keeping frame->ra_off == 0.

When the kernel unwinds the stack, unwind_user_next_common() would see
frame->ra_off == 0 and call unwind_user_get_ra_reg():

kernel/unwind/user.c:unwind_user_next_common() {
    ...
	if (frame->ra_off) {
		if (get_user_word(&ra, cfa, frame->ra_off, state->ws))
			return -EINVAL;
	} else {
		if (!state->topmost || unwind_user_get_ra_reg(&ra))
			return -EINVAL;
	}
    ...
}

Would it be better to gracefully return an error code like -EINVAL here
without raising a warning?

> +	return -EINVAL;
> +}

[ ... ]

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