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

[Jens Remus <jremus@linux.ibm.com>]

On 5/18/2026 4:57 PM, Jens Remus wrote:
> On 5/5/2026 8:35 PM, sashiko-bot@kernel.org wrote:
>> 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);
> 
> Replace with the following to resolve below issue:
> 
> 	dbg_once("unwind_user_get_ra_reg() not implemented\n");

Omit or replace by the following?

	pr_debug_once("%s (%d): unwind_user_get_ra_reg() not implemented\n",
		      current->comm, current->pid);

This did not work with dbg_once() defined in kernel/unwind/user.c as
follows, as linux/unwind_deferred.h includes linux/unwind_user.h and
therefore gets included into other modules that do not define dbg_once()
(e.g. via linux/irq-entry-common.h including linux/unwind_deferred.h).

Steven, Should I omit the dbg_once() or could I replace by the above
unguarded pr_debug_once()?


#ifdef CONFIG_DYNAMIC_DEBUG

#define dbg_once(fmt, ...)							\
	pr_debug_once("%s (%d): " fmt, current->comm, current->pid, ##__VA_ARGS__)

#else /* !CONFIG_DYNAMIC_DEBUG */

#define dbg_once(args...)		no_printk(args)

#endif /* !CONFIG_DYNAMIC_DEBUG */

> 
>>
>> 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.
> 
> Valid.  On architectures that pass the RA on the stack and therefore do
> not implement unwind_user_get_ra_reg(), such as x86-64, above
> WARN_ON_ONCE(1) can be triggered using forged .sframe that maliciously
> specifies the SFrame fixed RA offset (from CFA) as zero and has a SFrame
> FRE with either no RA and FP offsets with a RA padding offset of zero.
> 
>>
>> 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;
>>> +}
>>
>> [ ... ]
>>
> 
> Regards,
> Jens

Thanks and regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/