Re: [PATCH 6.12] x86/fgraph: Fix return_to_handler regs.rsp value

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The `return_to_handler` assembly routine creates a `pt_regs` (or `ftrace_regs`) structure on the kernel stack but only initializes four registers (`rax`, `rdx`, `rbp`, `rsp`), leaving the rest of the structure uninitialized. This partially initialized structure is passed to BPF kretprobe programs, leading to an information leak of kernel stack memory.
--

commit ff6f1024b92860971d84c833c6dac53501145715
Author: Jiri Olsa <jolsa@kernel.org>

x86/fgraph: Fix return_to_handler regs.rsp value

This commit fixes the unwinding rsp register value in return_to_handler. It 
saves the original rsp before the FRAME_SIZE adjustment, replacing the 
previous incorrect value. This ensures fprobe and direct unwinders see the 
right stack pointer.

Link: https://lore.kernel.org/bpf/20260126211837.472802-2-jolsa@kernel.org

> diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
> --- a/arch/x86/kernel/ftrace_64.S
> +++ b/arch/x86/kernel/ftrace_64.S
> @@ -364,6 +364,9 @@ SYM_CODE_START(return_to_handler)
>  	UNWIND_HINT_UNDEFINED
>  	ANNOTATE_NOENDBR
>  
> +	/* Store original rsp for pt_regs.sp value. */
> +	movq %rsp, %rdi
> +
>  	/* Restore return_to_handler value that got eaten by previous ret instruction. */
>  	subq $8, %rsp
>  	UNWIND_HINT_FUNC
> @@ -374,7 +377,7 @@ SYM_CODE_START(return_to_handler)
>  	movq %rax, RAX(%rsp)
>  	movq %rdx, RDX(%rsp)
>  	movq %rbp, RBP(%rsp)
> -	movq %rsp, RSP(%rsp)
> +	movq %rdi, RSP(%rsp)

[Severity: High]
This is a pre-existing issue, but could this code leak kernel stack memory
to BPF programs?

This assembly creates a pt_regs structure on the stack by allocating
FRAME_SIZE bytes, but only explicitly saves rax, rdx, rbp, and rsp. Later in
ftrace_return_to_handler and arch_ftrace_partial_regs, only a few additional
fields are populated.

The remaining fields (like rdi, rsi, rbx, and r12-r15) remain uninitialized.

Because this partially initialized pt_regs structure is passed to BPF
kprobe_multi return programs via kprobe_multi_link_exit_handler(), and the
BPF verifier allows reading any field of the pt_regs context, does this
allow BPF programs to extract residual kernel stack data?

>  	movq %rsp, %rdi
>  
>  	call ftrace_return_to_handler

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526192324.79459-1-gyokhan@amazon.de?part=1