Re: [PATCH bpf-next] bpf, arm32: Reject BPF_PSEUDO_CALL in the JIT

On Fri, Apr 17, 2026 at 12:25 PM <[email protected]> wrote:
>
> Sashiko AI review found 2 potential issue(s):
> - [High] The patch leaves the memory leak unpatched for BPF programs utilizing callbacks (BPF_PSEUDO_FUNC).
> - [Low] The patch introduces a C90 'declaration after statement' violation that will cause build failures on stable backports.
> --
>
> commit 5b49d0ae3429d9aefefa73b4cf12e6c41845458c
> Author: Puranjay Mohan <[email protected]>
>
> bpf, arm32: Reject BPF_PSEUDO_CALL in the JIT
>
> The ARM32 BPF JIT does not support subprograms. This patch rejects
> BPF_PSEUDO_CALL early in the JIT to prevent leaking a JIT binary
> allocation during the second pass in bpf_jit_subprogs().
>
> Link: https://lore.kernel.org/bpf/[email protected]
>
> > diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
> > index deeb8f292454b..91fef10e88bc4 100644
> > --- a/arch/arm/net/bpf_jit_32.c
> > +++ b/arch/arm/net/bpf_jit_32.c
> > @@ -2047,6 +2047,8 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
> >       /* function call */
> >       case BPF_JMP | BPF_CALL:
> >       {
> > +             if (insn->src_reg == BPF_PSEUDO_CALL)
> > +                     goto notyet;
> >               const s8 *r0 = bpf2a32[BPF_REG_0];
> >               const s8 *r1 = bpf2a32[BPF_REG_1];
> >               const s8 *r2 = bpf2a32[BPF_REG_2];
>
> Will this cause a build failure on older stable branches?
>
> This patch is a bugfix tagged for stable backports, but placing code before
> declarations violates the -Wdeclaration-after-statement rule enforced in
> kernels before 6.5. Should the check be moved below the local variable
> declarations?
>
> Also, does this leave the memory leak unpatched for programs utilizing
> callbacks like BPF_PSEUDO_FUNC?
>
> When a program uses a callback, the verifier creates a subprogram. During the
> first JIT pass, the ARM32 JIT ignores insn->src_reg and compiles the
> instruction successfully as a 64-bit immediate load.
>
> Because the first pass succeeds, bpf_jit_subprogs() executes its second pass,
> allocates a new binary, overwrites prog->bpf_func, and aborts with -ENOTSUPP,
> leaking the first allocation exactly as it did before this patch.
>
> Is an equivalent rejection needed for BPF_PSEUDO_FUNC in the
> BPF_LD | BPF_IMM | BPF_DW handler?

Yes, both reviews are correct, I will fix them in the next version.

Thanks