Re: [PATCH bpf-next v5 1/5] bpf: Move JIT for single-subprog programs to verifier

[Xu Kuohai]

On 3/2/2026 6:46 PM, bot+bpf-ci@xxxxxxxxxx wrote:
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index fc4ccd1de569..ab2bc0850770 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -26086,6 +26086,11 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr, __u3
> >   		convert_pseudo_ld_imm64(env);
> >   	}
> >
> > +	/* constants blinding in the JIT may increase prog->len */
> > +	len = env->prog->len;
> > +	if (env->subprog_cnt == 1)
> > +		env->prog = bpf_prog_select_jit(env->prog, &ret);
> > +
> >   	adjust_btf_func(env);
> >
> >   err_release_maps:
>
> [ ... ]
>
> > @@ -26111,7 +26116,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr, __u3
> >   err_unlock:
> >   	if (!is_priv)
> >   		mutex_unlock(&bpf_verifier_lock);
> > -	clear_insn_aux_data(env, 0, env->prog->len);
> > +	clear_insn_aux_data(env, 0, len);
> >   	vfree(env->insn_aux_data);
>
> Can the len variable be stale when reaching clear_insn_aux_data()
> through an error path?
>
> At the top of bpf_check(), len is first assigned as:
>
>      len = (*prog)->len;
>
> This original value is used to allocate insn_aux_data. Later,
> instruction rewriting passes like convert_ctx_accesses() and
> do_misc_fixups() can change env->prog->len and resize
> insn_aux_data to match via bpf_patch_insn_data().
>
> The second assignment added by this patch:
>
>      len = env->prog->len;
>
> is only reached on the success path, after all instruction
> rewriting and after the maps/btfs allocation. If an error occurs
> between the rewriting passes and this reassignment, for example
> bpf_vlog_finalize() returning an error, copy_to_bpfptr_offset()
> failing, or kmalloc for used_maps/used_btfs failing, the code
> jumps to err_release_maps and eventually reaches
> clear_insn_aux_data(env, 0, len) with the original program length
> rather than the current post-rewriting length.
>
> If rewriting increased env->prog->len (the common case for
> programs with context accesses), the iteration stops short of
> the actual insn_aux_data size, potentially leaking jt fields in
> the unvisited entries.

Right, len is stale in the error path. I'll fix it in the next version.

> ---
> 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/22571297111
>
> AI-authorship-score: low
> AI-authorship-explanation: Standard kernel refactoring by a known BPF contributor with non-native English patterns in the commit message.
> issues-found: 1
> issue-severity-score: low
> issue-severity-explanation: Stale len variable in bpf_check error paths can cause insn_aux_data jt field memory leaks when instruction rewriting changed prog->len before an error between rewriting and the len reassignment.