Re: [PATCH v11 7/8] powerpc/bpf: fix buffer overflow in JIT for large BPF programs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Silent branch offset truncation in exception table fixup generation.
--

--- Patch [7]: [PATCH v11 7/8] powerpc/bpf: fix buffer overflow in JIT for large BPF programs ---
commit 575dc92c1d10e63b9fc1ecf052e4cace5279974f
Author: Abhishek Dubey <adubey@linux.ibm.com>
Subject: powerpc/bpf: fix buffer overflow in JIT for large BPF programs

This commit fixes a buffer overflow during JIT compilation of large BPF
programs on PowerPC. It addresses an issue where the exit address was
unpopulated in the first pass, skipping the epilogue size calculation and
causing a buffer overflow in subsequent passes when the real exit address
required a full inline epilogue. The patch updates the multi-pass logic to
loop until the program size converges.

Link: https://lore.kernel.org/bpf/20260529015855.364704-2-adubey@linux.ibm.com/T/#mfcb23909d977b949727cca4f59ee56a13fd69b92

> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index 757b36bfbac35..2cc1124ed5303 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c

[ ... ]

> @@ -428,7 +446,7 @@ int bpf_add_extable_entry(struct bpf_prog *fp, u32 *image, u32 *fimage, int pass
>  	u32 *fixup;
>  
>  	/* Populate extable entries only in the last pass */
> -	if (pass != 2)
> +	if (pass < CODEGEN_MIN_PASSES)
>  		return 0;
>  
>  	if (!fp->aux->extable ||

[Severity: High]
This is a pre-existing issue, but since this patch explicitly targets
support for large BPF programs (exceeding the 32MB branch range), does the
exception table fixup generation also need an out-of-range branch check?

Looking at bpf_add_extable_entry() just below this hunk:

    fixup[BPF_FIXUP_LEN - 1] =
        PPC_RAW_BRANCH((long)(pc + jmp_off) - (long)&fixup[BPF_FIXUP_LEN - 1]);

Since PPC_RAW_BRANCH silently masks out-of-range offsets without returning
an error (unlike PPC_JMP which uses is_offset_in_branch_range()), could a
large BPF program with exception handlers result in a truncated branch
offset?

If a program has PROBE_MEM accesses and the offset between the fixup
routine and the main program exceeds 32MB, it seems the CPU might jump to
a corrupted address after handling the exception. Is it worth validating
the branch offset here as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1786099877.git.skb99@linux.ibm.com?part=7