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

[sashiko-bot@kernel.org]

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 <puranjay@kernel.org>

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/b63e9174-7a3d-4e22-8294-16df07a4af89@pengutronix.de

> 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?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260417103004.3552500-1-puranjay@kernel.org?part=1