Re: [PATCH bpf-next v4 24/25] bpf, arm64: Add JIT support for stack arguments

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Incoming stack arguments 6-8 are mapped to caller-saved registers `x5-x7` without being spilled to the stack, allowing them to be corrupted by function calls. This bypasses verifier bounds checks and enables arbitrary kernel memory read/write.
--

commit 20fea8a10865fdb2efc7f0e237022c9e2e575fd7
Author: Puranjay Mohan <puranjay@kernel.org>

bpf, arm64: Add JIT support for stack arguments

Implement stack argument passing for BPF-to-BPF and kfunc calls with
more than 5 parameters on arm64, following the AAPCS64 calling
convention.

> BPF convention uses fixed offsets from BPF_REG_PARAMS (r11): off=-8 is
> always arg 6, off=-16 arg 7, etc. The verifier invalidates all outgoing
> stack arg slots after each call, so the compiler must re-store before
> every call. This means x5-x7 don't need to be saved on stack.

While it is true that the verifier invalidates outgoing stack arg slots after
each call, does this logic safely apply to incoming stack arguments?

Incoming arguments are modeled as memory accesses relative to BPF_REG_PARAMS
and the verifier assumes these memory slots are preserved across helper and
subprog calls.

Since x5-x7 are caller-saved registers per AAPCS64, what happens if a BPF
program makes a call (which clobbers x5-x7) and subsequently reads its
incoming stack arguments 6-8?

> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
> index 085e650662e3d..e3bbeaa94590c 100644
> --- a/arch/arm64/net/bpf_jit_comp.c
> +++ b/arch/arm64/net/bpf_jit_comp.c

[ ... ]

> @@ -1191,6 +1207,41 @@ static int add_exception_handler(const struct bpf_insn *insn,
>  	return 0;
>  }
>  
> +static const u8 stack_arg_reg[] = { A64_R(5), A64_R(6), A64_R(7) };
> +
> +#define NR_STACK_ARG_REGS	ARRAY_SIZE(stack_arg_reg)
> +
> +static void emit_stack_arg_load(u8 dst, s16 bpf_off, struct jit_ctx *ctx)
> +{
> +	int idx = bpf_off / sizeof(u64) - 1;
> +
> +	if (idx < NR_STACK_ARG_REGS)
> +		emit(A64_MOV(1, dst, stack_arg_reg[idx]), ctx);

Could emit_stack_arg_load() read corrupted values if the BPF program reads
an incoming argument after making a helper or subprog call that clobbered
the x5-x7 registers?

If LLVM treats the incoming arguments as preserved memory and doesn't spill
them locally, a mismatch could occur where the verifier applies its bounds
tracking to the original argument but the program actually reads a clobbered
value, potentially leading to arbitrary memory reads or writes.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260513044949.2382019-1-yonghong.song@linux.dev?part=24