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

Yonghong Song
2026-04-27T20:42:34Z

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