Re: [PATCH v7 11/11] unwind: arm64: Use sframe to unwind interrupt frames

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] arm64: noinstr violation by calling sframe_find() in stack unwinder
--

commit 13ca4d55a43f451bf08442b7e6af494a6c23a78e
Author: Dylan Hatch <dylanbhatch@google.com>

unwind: arm64: Use sframe to unwind interrupt frames

This patch adds kunwind_next_regs_sframe() to unwind interrupt frames using
sframe info, falling back to frame-pointer unwinding on failure. It updates
the exception boundary unwinding logic to recover the return address more
reliably when sframe data is present.

> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index 3ebcf8c53fb04..5aaeac9611015 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
[ ... ]
> @@ -244,6 +247,162 @@ kunwind_next_frame_record(struct kunwind_state *state)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_HAVE_UNWIND_KERNEL_SFRAME
[ ... ]
> +/*
> + * Unwind from a pt_regs according to sframe.
> + */
> +static __always_inline int
> +kunwind_next_regs_sframe(struct kunwind_state *state)
> +{
> +	struct unwind_frame frame;
> +	unsigned long cfa, fp, ra;
> +	enum kunwind_source source = KUNWIND_SOURCE_FRAME;
> +	struct pt_regs *regs = state->regs;
> +
> +	int err;
> +
> +	if (WARN_ON_ONCE(state->source != KUNWIND_SOURCE_REGS_PC))
> +		return -EINVAL;
> +	if (WARN_ON_ONCE(!state->regs))
> +		return -EINVAL;
> +
> +	/* FP/SP alignment 8 bytes */
> +	if (state->common.fp & 0x7)
> +		return -EINVAL;
> +
> +	err = sframe_find(state->common.pc, &frame);

[Severity: High]
Does calling sframe_find() here violate the noinstr guarantee of the stack
unwinding path?

The unwind path is called via arch_stack_walk() -> kunwind_stack_walk() ->
kunwind_next() -> kunwind_next_regs_sframe().

Since arch_stack_walk() is explicitly marked noinstr to guarantee safe
execution in uninstrumentable contexts (like nmi), calling instrumentable
or rcu-protected functions like sframe_find() and __module_text_address()
could cause a recursive fault or kernel panic if tracing or kasan is active.

Additionally, could accessing rcu-protected module structures without rcu
watching lead to use-after-free bugs when stack unwinding is routinely
triggered by tools like perf or bpf tracing?

> +	if (err)
> +		return -EINVAL;
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918224157.1471085-1-dylanbhatch@google.com?part=11