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

[Jiri Olsa <olsajiri@gmail.com>]

On Tue, May 26, 2026 at 07:50:07PM +0000, sashiko-bot@kernel.org wrote:
> 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?

I think because kprobe/bpf is root only, it's not really an issue,
cc-ing Steven and Masami

jirka