Re: [PATCH bpf-next v5 00/16] bpf: Support stack arguments for BPF functions and kfuncs

[Puranjay Mohan <puranjay@kernel.org>]

Yonghong Song <yonghong.song@linux.dev> writes:

> Currently, bpf function calls and kfunc's are limited by 5 reg-level
> parameters. For function calls with more than 5 parameters,
> developers can use always inlining or pass a struct pointer
> after packing more parameters in that struct. But there is
> no workaround for kfunc if more than 5 parameters is needed.
>
> This patch set lifts the 5-argument limit by introducing stack-based
> argument passing for BPF functions and kfunc's, coordinated with
> compiler support in LLVM [1]. The compiler emits loads/stores through
> a new bpf register r11 (BPF_REG_PARAMS) to pass arguments beyond
> the 5th, keeping the stack arg area separate from the r10-based program
> stack. The maximum number of arguments is capped at MAX_BPF_FUNC_ARGS
> (12), which is sufficient for the vast majority of use cases.
>
> In verifier, r11 based stores can survive bpf-to-bpf and kfunc
> calls. For example
>       *(u64 *)(r11 - 8) = r6;
>       *(u64 *)(r11 - 16) = r7;
>       call bar1;                // arg6 = r6, arg7 = r7
>       call bar2;                // reuses same arg6, arg7 without re-storing

Argument registers are caller saved, that means if the x86 JIT will use
R9 for the arg6 and call bar1, it can clobber it (by calling a helper or
another bpf-to-bpf call) and then bar2 will receive clobbered value for
arg6 because it did not reload it.

This only works for caller saved registers like arg5 (R8 on x86-64) (R5
on bpf) because R5 (BPF) is caller saved and compiler will make sure to
save R5 before the call. But for stacked arguments, compiler models them
as stack memory and if the JIT models them as a register to follow
calling convention, they need to be saved/reloaded before calls. 

Let me explain with an example, if you apply this patch to the selftests:

-- >8 --

From 52924eb28056fe8a2321b1cadf9409f6ca90603d Mon Sep 17 00:00:00 2001
From: Puranjay Mohan <puranjay@kernel.org>
Date: Sat, 18 Apr 2026 09:11:06 -0700
Subject: [PATCH] selftests/bpf: Add test for stack arg register clobbering

Add verifier test stack_arg_reuse_across_inner_call which uses inline
asm to store stack args, call a subprog that internally calls another
subprog with different stack arg values (100, 200 instead of 6, 7),
then reuse the original stores for a second call without re-storing.

This exposes JIT bugs where stack arg registers (x5-x7 on arm64, R9
on x86) are clobbered by the inner call but not refreshed before
the second call.

Correct result: 315 + 28 = 343.
Clobbered result: 315 + 315 = 630. (on arm64)

Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
---
 .../selftests/bpf/progs/verifier_stack_arg.c  | 56 +++++++++++++++++++
 1 file changed, 56 insertions(+)

diff --git a/tools/testing/selftests/bpf/progs/verifier_stack_arg.c b/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
index 41ce950ea40e..0c6b433404e8 100644
--- a/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
+++ b/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
@@ -462,6 +462,62 @@ __naked void stack_arg_sequential_calls(void)
        );
 }

+/*
+ * subprog_7args_inner_call takes 7 args like subprog_7args, but
+ * internally calls subprog_7args with different stack arg values
+ * (100, 200).  This clobbers whatever the JIT placed in the stack
+ * arg registers (x5-x7 on arm64, R9 on x86).
+ */
+__noinline __used
+static int subprog_7args_with_inner_call(int a, int b, int c, int d,
+                                        int e, int f, int g)
+{
+       return subprog_7args(a, b, c, d, e, 100, 200);
+}
+
+SEC("tc")
+__description("stack_arg: store reuse across inner call")
+__success __retval(343)
+__arch_x86_64
+__arch_arm64
+__naked void stack_arg_reuse_across_inner_call(void)
+{
+       asm volatile (
+               /* call1: subprog_7args_inner_call(1,2,3,4,5,6,7)
+                * internally calls subprog_7args(1,2,3,4,5,100,200)=315
+                * which clobbers stack arg registers with 100, 200.
+                * Returns 315.
+                */
+               "r1 = 1;"
+               "r2 = 2;"
+               "r3 = 3;"
+               "r4 = 4;"
+               "r5 = 5;"
+               "*(u64 *)(r11 - 8) = 6;"
+               "*(u64 *)(r11 - 16) = 7;"
+               "call subprog_7args_with_inner_call;"
+               "r6 = r0;" /* 315 */
+               /* call2: reuse r11 stores from call1 (no re-store).
+                * subprog_7args(1,2,3,4,5,6,7) should return 28.
+                * If clobbered: subprog_7args(1,2,3,4,5,100,200)=315.
+                */
+               "r1 = 1;"
+               "r2 = 2;"
+               "r3 = 3;"
+               "r4 = 4;"
+               "r5 = 5;"
+               /*
+                * the 6th and 7th arg should be 6, 7 as set above.
+                * But the inner call in subprog_7args_inner_call clobbered
+                * them and reusing again without a re-store will be wrong.
+                */
+               "call subprog_7args;" /* should return 28, but will be 315 due to clobber */
+               "r0 += r6;" /* should have 315 + 28 = 343 but will be 315 + 315 = 630 */
+               "exit;"
+               ::: __clobber_all
+       );
+}
+
 #else

 SEC("socket")
--
2.52.0

-- 8< --

If I run this arm64 (I have a patch to add support)

I get:
run_subtest:PASS:obj_open_mem 0 nsec
run_subtest:PASS:unexpected_load_failure 0 nsec
do_prog_test_run:PASS:bpf_prog_test_run 0 nsec
run_subtest:FAIL:1313 Unexpected retval: 630 != 343
#631/14  verifier_stack_arg/stack_arg: store reuse across inner
call:FAIL

And on x86 it will be:
  - Second call gets R9 = 100 (clobbered), [rsp+0] = 7 (survives, because subprog get's own stack slot)
  - subprog_7args(1,2,3,4,5, 100, 7) = 122 instead of 28
  - Total: 315 + 122 = 437 instead of 343

^^ this is not tested just a theoretical looking at x86 JIT code added
in this patchset that used R9 for sixth argument.

So, I think the fix it to make the JITs keep the 6th arg (x86) and
(6,7,8)th arg (arm64) on the stack and re-load them before every call.
Or the compiler should treat all r11 stack slots like caller saved stack
and reload them.

Please let me know if my analysis is correct or maybe my arm64 jit
implementation is broken.

Thanks,
Puranjay