Re: [PATCH bpf-next 17/18] bpf, arm64: Add JIT support for stack arguments

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

On 4/27/26 2:06 AM, Puranjay Mohan wrote:
> bot+bpf-ci@kernel.org writes:
>
>>> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
>>> --- a/arch/arm64/net/bpf_jit_comp.c
>>> +++ b/arch/arm64/net/bpf_jit_comp.c
>> [ ... ]
>>
>>> @@ -1671,7 +1727,7 @@
>>>   	}
>>>   	if (src == fp) {
>>>   		src_adj = ctx->priv_sp_used ? priv_sp : A64_SP;
>>> -		off_adj = off + ctx->stack_size;
>>> +		off_adj = off + ctx->stack_size + ctx->stack_arg_size;
>>>   	} else {
>>>   		src_adj = src;
>>>   		off_adj = off;
>> When priv_sp_used is true, does this offset calculation produce correct
>> addresses for BPF fp-relative accesses?
>>
>> Looking at build_prologue:
>>
>> arch/arm64/net/bpf_jit_comp.c:build_prologue() {
>>      ...
>>      emit(A64_MOV(1, fp, priv_sp), ctx);
>>      emit(A64_ADD_I(1, fp, fp, ctx->stack_size), ctx);  /* line 612 */
>>
>>      if (ctx->stack_size && !ctx->priv_sp_used)
>>          emit(A64_SUB_I(1, A64_SP, A64_SP, ctx->stack_size), ctx);  /* line 620 */
>>
>>      if (ctx->stack_arg_size)
>>          emit(A64_SUB_I(1, A64_SP, A64_SP, ctx->stack_arg_size), ctx);  /* line 623 */
>>      ...
>> }
>>
>> When priv_sp_used is true:
>> - fp = priv_sp + stack_size (line 612)
>> - main SP is not decremented by stack_size (skipped at line 620)
>> - main SP is decremented by stack_arg_size (line 623-624)
>>
>> So the BPF program data lives on the private stack, while outgoing stack
>> args live on the real SP. These are separate memory regions.
>>
>> In build_insn, the computed address for fp-relative loads/stores becomes:
>>      addr = priv_sp + off + stack_size + stack_arg_size
>>
>> But the intended BPF address is:
>>      addr = fp + off = priv_sp + stack_size + off
>>
>> The computed address is stack_arg_size bytes too high, accessing memory
>> above the intended location on the private stack.
>> This would read/write into the private-stack guard region (16 bytes) or
>> past it when stack_arg_size > 16. Can this occur?  The verifier only
>> forbids tail_calls + stack_args (verifier.c:5657), not priv_stack +
>> stack_args. A kprobe BPF program that uses BPF_REG_FP and calls a kfunc
>> with 9+ arguments would trigger wrong memory accesses.
> This analysis is correct, will fix in the next version.

Thanks Puranjay, once you fixed this issue, I can submit next revision
with your and my fixes.

>
>> Note that x86's bpf_int_jit_compile prevents priv_stack allocation when
>> stack_arg_depth != 0 (x86/bpf_jit_comp.c:3883). The arm64 version has no
>> equivalent guard.
>>
>> The same issue affects the ST case:
>>
>>
[...]

>> ---
>> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
>> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>>
>> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24902767240