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

[sashiko-bot@kernel.org]

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

New issues:
- [Critical] The patch introduces a guaranteed buffer overflow for BPF programs larger than 32MB by failing to clear `cgctx.alt_exit_addr` before the second size-calculation pass (pass 0).

Pre-existing issues:
- [Critical] This problem wasn't introduced by this patch, but the patch exposes it fatally: missing update of `addrs[fp->len]` during JIT passes causes `BPF_EXIT` to branch to uninitialized memory, crashing the kernel.
--

commit 7f31e323d670ec5c6b2df079f524622af737b8e6
Author: Abhishek Dubey <adubey@linux.ibm.com>

powerpc/bpf: fix buffer overflow in JIT for large BPF programs

During pass 0 (size calculation), exit_addr is 0 since addrs[fp->len]
is not yet populated. bpf_jit_emit_exit_insn() treats a zero exit_addr
as in-range and skips bpf_jit_build_epilogue(), so the alternate inline
epilogue instructions are not counted in alloclen.

Closes: 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 2e2993bc646e5..032918f192b1f 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -128,11 +128,10 @@ void bpf_jit_build_fentry_stubs(u32 *image, u32 *fimage, struct codegen_context
>  int bpf_jit_emit_exit_insn(u32 *image, u32 *fimage, struct codegen_context *ctx,
>  							int tmp_reg, long exit_addr)
>  {
> -	if (!exit_addr || is_offset_in_branch_range(exit_addr - (ctx->idx * 4))) {
> +	if (exit_addr && is_offset_in_branch_range(exit_addr - (long)(ctx->idx * 4))) {
>  		PPC_JMP(exit_addr);
> -	} else if (ctx->alt_exit_addr) {
> -		if (WARN_ON(!is_offset_in_branch_range((long)ctx->alt_exit_addr - (ctx->idx * 4))))
> -			return -1;
> +	} else if (ctx->alt_exit_addr &&
> +		is_offset_in_branch_range(ctx->alt_exit_addr - (long)(ctx->idx * 4))) {

[Severity: Critical]
For programs larger than 32MB, bpf_int_jit_compile() runs a second size
calculation pass (pass 0). Since cgctx.alt_exit_addr isn't cleared before
this second pass, could this condition evaluate to true using the stale
offset from the first pass?

If this happens, pass 0 would skip the inline epilogue and emit a single
jump instead, undercalculating the buffer size. Would passes 1 and 2 then
write past the end of the allocated buffer, corrupting kernel memory?

[Severity: Critical]
This is a pre-existing issue, but this patch appears to expose it fatally.

In bpf_int_jit_compile(), addrs[fp->len] is set after pass 0:

	addrs[fp->len] = cgctx.idx * 4;

However, it is never updated inside the subsequent loop for passes 1 and 2.

Because pass 0 now generates a significantly larger body (building a full
inline epilogue for the first BPF_EXIT), passes 1 and 2 will shrink. Since
addrs[fp->len] isn't updated for the new shrunken body sizes, BPF_EXIT
instructions in pass 2 will branch to the old pass 0 offset.

This offset points past the actual generated epilogue into the breakpoint
padding. Could this cause a kernel panic when the BPF program executes?

>  		PPC_JMP(ctx->alt_exit_addr);
>  	} else {
>  		ctx->alt_exit_addr = ctx->idx * 4;
>  		bpf_jit_build_epilogue(image, fimage, ctx);
>  	}
> 
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611153826.31187-1-adubey@linux.ibm.com?part=7