Re: [PATCH bpf] libbpf: Reject excessive program counts in generated loaders

[Mahe Tardy]

On Thu, Oct 29, 2026 at 04:33:56PM +0000, Alexei Starovoitov wrote:
> On Wed, Oct 28, 2026 at 11:39 AM Mahe Tardy <mahe.tardy@xxxxxxxxx> wrote:
> > @@ -122,6 +122,11 @@ void bpf_gen__init(struct bpf_gen *gen, int log_level, int nr_progs, int nr_maps
> > +	if (nr_progs > MAX_USED_PROGS) {
> > +		pr_warn("Total programs exceeds %d\n", MAX_USED_PROGS);
> > +		gen->error = -E2BIG;
> > +		return;
> > +	}
> 
> nr_progs is obj->nr_programs. It counts subprogs and progs with
> autoload == false too. See commit 259172bb6514
> ("libbpf: Fix gen_loader assumption on number of programs.").
> Only a prog that reaches bpf_gen__prog_load() takes a slot in prog_fd[].
> 
> Two objects with obj->nr_programs == 33:
> 
>   object               today            this patch     should be
>   -------------------  ---------------  -------------  -------------
>   33 progs             -EACCES at load  -E2BIG at gen  -E2BIG at gen
>   1 prog, 32 subprogs  -EACCES at load  -E2BIG at gen  loads
> 
> The second object fails today because of the cleanup loop in
> bpf_gen__init(). It closes nr_progs slots of prog_fd[], and
> prog_fd[32] is at r10 + 0:
> 
>   r1 = *(u32 *)(r10 +0)
>   invalid read from stack R10 off=0 size=4
> 
> Lets fix both: clamp the loop and check the limit where a prog takes
> the slot, like add_map_fd() does.
> Something like this (not even compile tested):
> 
> diff --git a/tools/lib/bpf/gen_loader.c b/tools/lib/bpf/gen_loader.c
> --- a/tools/lib/bpf/gen_loader.c
> +++ b/tools/lib/bpf/gen_loader.c
> @@ -139,6 +139,8 @@ void bpf_gen__init(struct bpf_gen *gen, int log_level, int nr_progs, int nr_maps
>  	emit(gen, BPF_MOV64_IMM(BPF_REG_3, 0));
>  	emit(gen, BPF_EMIT_CALL(BPF_FUNC_probe_read_kernel));
>  
> +	/* nr_progs includes subprogs and progs that are not loaded */
> +	nr_progs = min(nr_progs, MAX_USED_PROGS);
>  	/* amount of stack actually used, only used to calculate iterations, not stack offset */
>  	nr_progs_sz = offsetof(struct loader_stack, prog_fd[nr_progs]);
>  	/* jump over cleanup code */
> @@ -1134,6 +1136,11 @@ void bpf_gen__prog_load(struct bpf_gen *gen,
>  		gen->attach_kind = 0;
>  	}
>  	emit_check_err(gen);
> +	if (gen->nr_progs == MAX_USED_PROGS) {
> +		pr_warn("Total programs exceeds %d\n", MAX_USED_PROGS);
> +		gen->error = -E2BIG;
> +		return;
> +	}
>  	/* remember prog_fd in the stack, if successful */
>  	emit(gen, BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_7,
>  			      stack_off(prog_fd[gen->nr_progs])));
> 
> since it was already applied. pls send a follow up.

Ah yes this is correct, I bumped into this trying extend the lskel (but
mostly trying to understand their generation for now to be honest) to
allow them to call BPF_LINK_CREATE and somehow I adjusted the nr_progs
passed to bpf_gen__init() earlier to the actual number of progs so I was
not paying attention.

Your patch makes sense to me now and works locally (since
bpf_object__load_progs() is filtering the subprogs and autoload=false we
have at the stage of filling the prog_fd, of course, the correct number
of progs), I tested on an object with 1 prog and 32 subprogs and it's
good now.

I'll send this shortly! Thanks!