Re: [bpf v8 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:

Pre-existing issues:
- [Critical] The patch fails to fully fix the 'branching past the real epilogue' bug because it does not handle code shrinkage during the final JIT pass, leading to a corrupted epilogue and guaranteed kernel panic.
- [High] The percpu private stack (`priv_stack_ptr`) is leaked on BPF JIT error paths when compilation fails after the image buffer is allocated.
--

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

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

This commit addresses a buffer overflow in the powerpc BPF JIT by ensuring
the alternate inline epilogue instructions are counted during size calculation
in pass-0. It also resets alt_exit_addr and recomputes the epilogue address
at the end of each pass.

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 c5a2874469221..baacb2855c072 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
[ ... ]
> @@ -347,6 +347,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_verifier_env *env, struct bpf_pr
>  			bpf_jit_binary_pack_free(fhdr, hdr);
>  			goto out_err;
>  		}
> +		addrs[fp->len] = cgctx.idx * 4;
>  		bpf_jit_build_epilogue(code_base, fcode_base, &cgctx);

[Severity: Critical]
This is a pre-existing issue, but does the fixed 2-pass compilation
loop fail to handle code shrinkage during the final JIT pass?

It seems the PowerPC JIT uses a fixed 2-pass compilation loop rather than
looping until the program size converges. While adding the assignment of
addrs[fp->len] updates the epilogue offset for the next pass, during pass 2,
an early exit that was out-of-range in pass 0 might now be within the 32MB
range of the pass 1 epilogue offset.

If this happens, it will emit a jump instead of an inline epilogue, causing
pass 2 to shrink. The pass 2 epilogue is then written at an earlier offset,
mathematically guaranteeing that it overwrites the first 4 bytes of the pass 1
epilogue.

When executed, a jump targeting the pass 1 epilogue offset would immediately
execute the instruction that replaced it (often a return instruction like blr),
returning without restoring the stack pointer or non-volatile registers. Could
this lead to memory corruption and a kernel panic?

Also, looking at the error handling path later in bpf_int_jit_compile():

arch/powerpc/net/bpf_jit_comp.c:bpf_int_jit_compile() {
[ ... ]
out_addrs:
		if (!image && priv_stack_ptr) {
			fp->aux->priv_stack_ptr = NULL;
			free_percpu(priv_stack_ptr);
		}
[ ... ]

[Severity: High]
This is a pre-existing issue, but does this code leak the percpu private
stack (priv_stack_ptr) on BPF JIT error paths when compilation fails after
the image buffer is allocated?

If bpf_jit_build_body() fails during pass 1 or 2 (for instance, due to an
unsupported instruction or a branch remaining out of range), the code frees
the image buffers and jumps to out_err.

The cleanup logic at out_addrs uses the condition if (!image && priv_stack_ptr)
to determine if the percpu stack should be freed. Because the image was
successfully allocated earlier, !image is false, and the free_percpu() call
is bypassed.

Since the JIT compilation failed, fp->jited remains 0. When the program is
subsequently destroyed via the standard bpf_jit_free() which checks
if (fp->jited), the function completely skips freeing priv_stack_ptr.

Could unprivileged users repeatedly load large BPF programs that pass the
verifier but intentionally fail JITing to exhaust percpu memory?

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