> Helper callbacks enter BPF subprograms through bpf_callback_t, whose
> runtime ABI supplies five arguments. BTF validation nevertheless permits
> static callback subprograms to declare more than five arguments when JIT
> stack arguments are supported.
>
> This lets verifier state for a callback use outgoing stack argument slots
> prepared at the helper call site. The helper does not pass those slots. On
> x86-64, callback loads of arguments seven and later therefore read the
> helper native frame instead of the synthetic values checked by the
> verifier. KASAN reports a slab OOB write.
This isn't a bug, but would it be worth extending this paragraph to cover
argument six as well? The new check rejects everything above five args,
and arch/x86/net/bpf_jit_comp.c documents that incoming arg 6 is read from
R9, which similarly doesn't match the value the verifier believes the
caller stored at r11-8.
[ ... ]
> diff --git a/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
> b/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
> index 7e0ce5db28a0..5acc3b63ca84 100644
> --- a/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
> +++ b/tools/testing/selftests/bpf/progs/verifier_stack_arg.c
> @@ -79,6 +86,32 @@ __naked void stack_arg_two_subprogs(void)
> );
> }
>
> +SEC("tc")
> +__description("stack_arg: callback with incoming stack args")
> +__failure
> +__msg("callback subprog cannot have stack args")
> +__naked void stack_arg_callback_many_args(void)
> +{
> + asm volatile (
> + "r6 = 0;"
> + "*(u64 *)(r11 - 32) = 0;"
> + "*(u64 *)(r11 - 24) = 0;"
> + "*(u64 *)(r11 - 16) = 0;"
> + "*(u64 *)(r11 - 8) = 0;"
> + "r1 = 1;"
> + "r2 = %[callback_9args];"
> + "r3 = 0;"
> + "r4 = 0;"
> + "call %[bpf_loop];"
> + "r0 = 0;"
> + "exit;"
> + :
> + : __imm_ptr(callback_9args),
> + __imm(bpf_loop)
> + : __clobber_all
> + );
> +}
This isn't a bug, but could the unused 'r6 = 0' be dropped? It's written
but never read, and the asm clobber list is __clobber_all.
Also, would a one-line comment on the four r11 stores help the next
reader? They're what makes the outgoing stack-arg slots initialized so
the new check is the one that fires.
---
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/31972309086
