Re: [PATCH bpf-next v2 16/18] bpf, x86: Allow programs 2 KiB of stack

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Thu Sep 24, 2026 at 11:13 AM CEST, bot+bpf-ci wrote:
>> diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
>> index eb19c945f4d5..be5fc4ac00d6 100644
>> --- a/Documentation/bpf/bpf_design_QA.rst
>> +++ b/Documentation/bpf/bpf_design_QA.rst
>
> [ ... ]
>
>> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>> index 9fbef7504e51..e2e531dd1e0b 100644
>> --- a/arch/x86/net/bpf_jit_comp.c
>> +++ b/arch/x86/net/bpf_jit_comp.c
>> @@ -4520,6 +4520,18 @@ bool bpf_jit_supports_subprog_tailcalls(void)
>>  	return true;
>>  }
>>
>> +/*
>> + * Frame sizes are 32-bit immediates in the prologue, epilogue and tail call
>> + * sequences, a tail call pops the caller's frame and lands in the target's
>> + * prologue before the target allocates its own, and private stacks are
>> + * allocated from the program's own depth, so MAX_BPF_STACK_JIT frames need
>> + * nothing special.
>> + */
>> +bool bpf_jit_supports_large_stack(void)
>> +{
>> +	return true;
>> +}
>> +
>
> Can a sched_cls or lwt_xmit program overflow the kernel stack through
> bpf_clone_redirect() recursion?
>
> A TC egress program on device X that calls bpf_clone_redirect(skb,
> X_ifindex, 0) redirects the packet back to itself. The redirect happens
> while the calling program's frame is on the stack:
>
>   bpf_clone_redirect()
>     __bpf_redirect()
>       __bpf_redirect_common()
>         __bpf_tx_skb()
>           dev_queue_xmit()
>             __dev_queue_xmit()
>               sch_handle_egress()
>                 tcx_run()
>                   bpf_prog_run() -> (same or another tc egress program)
>
> The guard in __bpf_tx_skb() (net/core/filter.c) only fails when the
> counter exceeds XMIT_RECURSION_LIMIT (8):
>
>   if (dev_xmit_recursion()) {
>       net_crit_ratelimited("bpf: recursion limit reached on datapath, buggy bpf program?\n");
>       kfree_skb(skb);
>       return -ENETDOWN;
>   }
>
> So dev_xmit_recursion() allows values 0 through 8 before it fails, which
> means the program runs at nesting levels 0 through 9. That puts ten of
> its frames on the stack at once.
>
> sched_cls programs never get a private stack:
>
>   kernel/bpf/verifier.c:bpf_enable_priv_stack() returns NO_PRIV_STACK
>   for them
>
> so their frames live on the task or IRQ stack. On x86-64 without KASAN
> that stack is 16 KiB (THREAD_SIZE_ORDER = IRQ_STACK_ORDER = 2).
>
> With this patch, a single 2048-byte frame is accepted. The BPF frames
> alone then take 10 x 2048 = 20 KiB, before any kernel frames in each
> round. That exceeds 16 KiB, so the stack overflows.
>
> Before this patch the same program was capped at 10 x 512 = 5 KiB of BPF
> frames, which fit. The recursion limit was meant to stop a buggy program
> from crashing the kernel.
>
> The commit message says nested programs "are not accounted against each
> other before or after this change; each level of nesting may now add up
> to 1.5 KiB more." It does not bound how many levels there can be. Here
> the kernel allows up to 10, which adds about 15 KiB compared to before.
>
> The same construction works through lwt_xmit programs, which also get
> bpf_clone_redirect(). Triggering the overflow needs CAP_BPF and
> CAP_NET_ADMIN to attach.
>
>

 Right, thanks; for v3 a program that calls bpf_clone_redirect() keeps the
 512-byte budget, since it can run ten frames deep through the datapath's
 recursion limit, and tests cover both bpf_clone_redirect() and bpf_redirect().

> ---
> 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/35976322553