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

[Yonghong Song <yonghong.song@linux.dev>]

On 5/15/26 10:20 AM, sashiko-bot@kernel.org wrote:
> 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?

Verifier will reject this. The call will clear all stack arg slots, so
subsequent read of incoming stack arguments will be rejected by verifier.

>
>> 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?

Verifier will reject this as load (read) cannot be behind helper/subprog-call/kfunc
and store (write).

>
> 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.
>