Re: [PATCH bpf-next v2 12/18] bpf: Size the per-frame verifier structures for a 2 KiB stack

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

On Thu Sep 24, 2026 at 11:13 AM CEST, bot+bpf-ci wrote:
>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>> index 3ff1d4f753d3..f7964410f330 100644
>> --- a/include/linux/bpf_verifier.h
>> +++ b/include/linux/bpf_verifier.h
>
> [ ... ]
>
>> @@ -243,12 +244,13 @@ enum bpf_stack_slot_type {
>>  #define BPF_REG_SIZE 8	/* size of eBPF register in bytes */
>>
>>  /*
>> - * Largest number of BPF_REG_SIZE stack slots a single frame can have. A frame
>> - * may use any part of the MAX_BPF_STACK budget; check_max_stack_depth()
>> - * enforces the bound on the combined depth of frames sharing the kernel stack
>> - * and on each frame using a private stack.
>> + * Largest number of BPF_REG_SIZE stack slots a single frame can have, sized
>> + * for the largest stack budget any JIT supports. A frame may use any part of
>> + * its program's budget; check_max_stack_depth() enforces the budget on the
>> + * combined depth of frames sharing the kernel stack and on each frame using
>> + * a private stack.
>>   */
>> -#define MAX_BPF_STACK_SLOTS	(MAX_BPF_STACK / BPF_REG_SIZE)
>> +#define MAX_BPF_STACK_SLOTS	(MAX_BPF_STACK_JIT / BPF_REG_SIZE)
>
> Can raising MAX_BPF_STACK_SLOTS to 256 cause an allocation overflow in
> the arg tracker?
>
> This change affects subprog_spill_slots() in kernel/bpf/liveness.c, which
> sizes the per-instruction stack tracking:
>
> kernel/bpf/liveness.c:subprog_spill_slots() {
>     return clamp_t(u32, DIV_ROUND_UP(deepest, 8),
>                    MAX_BPF_STACK / BPF_REG_SIZE, MAX_BPF_STACK_SLOTS);
> }
>
> Before this patch that was clamp(x, 64, 64), always returning 64. Now any
> BPF_DW instruction with base R10 and a negative offset can push nslots up
> to 256. The value feeds compute_subprog_args():
>
> kernel/bpf/liveness.c:compute_subprog_args() {
>     at_stack_in = kvmalloc_objs(*at_stack_in, (size_t)len * nslots,
>                                  GFP_KERNEL_ACCOUNT);
> }
>
> with sizeof(struct arg_track) == 10.
>
> This runs from bpf_compute_live_registers() before do_check_main().
> The instruction checks in check_and_resolve_insns() and check_insn_fields()
> do not validate R10 offsets, so an instruction such as
> '*(u64 *)(r10 - 2048) = 0' in a program the main pass would later reject
> still reaches this allocation with nslots == 256.
>
> A bpf_capable loader may submit up to BPF_COMPLEXITY_LIMIT_INSNS
> (1,000,000) instructions. For a single subprog with len >= 838,861 and
> nslots == 256, or len == 1,000,000 and offset <= -1713 (nslots >= 215),
> the size becomes len * nslots * 10 > INT_MAX.
>
> The kvmalloc path checks this:
>
> mm/util.c:__kvmalloc_node_noprof() {
>     if (unlikely(size > INT_MAX)) {
>         WARN_ON_ONCE(!(flags & __GFP_NOWARN));
>         return NULL;
>     }
> }
>
> GFP_KERNEL_ACCOUNT has no __GFP_NOWARN, so userspace can trigger a kernel
> WARN (a panic with panic_on_warn). The load then fails with -ENOMEM instead
> of the expected -EACCES or -EINVAL. The old worst case was
> 1,000,000 * 64 * 10 = 640 MB, below INT_MAX.
>
> Even below the WARN threshold, the arg tracker now allocates and iterates
> up to 4x more stack state (up to about 2 GB) for programs that will be
> rejected at the 512-byte budget anyway.
>
> Could the clamp bound nslots by the program's stack budget instead of
> MAX_BPF_STACK_SLOTS, to match what the main pass will eventually allow?
>

Fixed for v3: the tracker is bounded by the program's stack budget, so a
512-byte program is back to the old 64-slot worst case, and the allocation uses
__GFP_NOWARN so the remaining pathological 2 KiB case fails the load with
-ENOMEM instead of warning.

> [ ... ]
>
>
> ---
> 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