On Tue, 2026-08-18 at 08:23 -0700, Yonghong Song wrote:
>
> On 8/17/26 1:48 PM, Jérémy Jean wrote:
> > 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.
> >
> > Reject callback subprograms with incoming stack arguments when processing
> > callback calls.
> >
> > Fixes: 0f6bd5e7a804 ("bpf: Support stack arguments for bpf functions")
> > Assisted-by: Codex:gpt-5
> > Signed-off-by: Jérémy Jean <[email protected]>
> > ---
> > kernel/bpf/verifier.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index fdc5fbb1f78c..5fcefc0eaba0 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -9285,6 +9285,8 @@ static int push_callback_call(struct bpf_verifier_env
> > *env, struct bpf_insn *ins
> > err = btf_check_subprog_call(env, subprog, caller->regs);
> > if (err == -EFAULT)
> > return err;
> > + if (bpf_in_stack_arg_cnt(&env->subprog_info[subprog]))
> > + return -EINVAL;
>
> This is not good as user will not know why it failed. Your v1 does have an
> error message.
>
> But this is not needed. Without above verifer.c change, user will get an
> error message:
> func#0 writes 4 stack arg slots, but calls only require 0
>
> NACK, see my v1 comment:
> https://lore.kernel.org/bpf/[email protected]/
>
> >
> > /* set_callee_state is used for direct subprog calls, but we are
> > * interested in validating only BPF helpers that can call subprogs as
Yonghong,
this is a real bug. Here is an example of a program that exposes
unsafe behavior:
unsigned long arr[10];
__noinline __used
static int callback_9args(__u32 index, void *ctx, long a3, long a4,
long a5, long a6, long a7, long a8, long a9)
{
return arr[a9] % 2; // verifier sees a9 as 0 and allows this
memory access
}
SEC("tc")
__description("stack_arg: callback with incoming stack args")
__failure
__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];"
"r1 = 1;"
"r2 = 2;"
"r3 = 3;"
"r4 = 4;"
"r5 = 5;"
"*(u64 *)(r11 - 32) = 0;"
"*(u64 *)(r11 - 24) = 0;"
"*(u64 *)(r11 - 16) = 0;"
"*(u64 *)(r11 - 8) = 0;"
"call callback_9args;" // this hides the callback call
from the check in bpf_fixup_call_args()
"r0 = 0;"
"exit;"
:
: __imm_ptr(callback_9args),
__imm(bpf_loop)
: __clobber_common, "r6"
);
}
Jérémy,
Please update the test case as above, as your test case does not
really expose the bug. Also, I think that a better fix would be to
make stack arguments not-init in the callback frame. This way the
verifier would produce a proper error message.
