Re: [PATCH v13 2/8] powerpc64/bpf: fix percpu private stack leak on JIT failure

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The ARM64 BPF JIT compiler leaks the percpu private stack on JIT failure.
- [High] bpf_jit_binary_pack_finalize uses uninitialized memory for size on failure, causing a system crash and leaking modmem charges.
--

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

powerpc64/bpf: fix percpu private stack leak on JIT failure

The existing conditional statement in bpf_int_jit_compile() frees the
percpu private stack only when the image buffer was never allocated.
If bpf_jit_build_body() fails, the image buffer is already allocated,
so the percpu stack is not freed and leaks. This fix implements freeing
the private stack whenever fp->jited was not set, i.e., compilation did
not succeed.

Link: https://lore.kernel.org/bpf/20260616135426.A06B71F000E9@smtp.kernel.org

> diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
> index a875521ff904d..8f7501954d9f0 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -357,7 +357,7 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_verifier_env *env, struct bpf_pr
>  				(void *)fimage + FUNCTION_DESCR_SIZE);
>  
>  out_addrs:
> -		if (!image && priv_stack_ptr) {
> +		if (!fp->jited && priv_stack_ptr) {
>  			fp->aux->priv_stack_ptr = NULL;
>  			free_percpu(priv_stack_ptr);
>  		}

arch/arm64/net/bpf_jit_comp.c:bpf_int_jit_compile() {
...
out_off:
		if (!ro_header && priv_stack_ptr) {
			free_percpu(priv_stack_ptr);
			prog->aux->priv_stack_ptr = NULL;
		}
...
}

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing this fix I
noticed a similar issue in the ARM64 JIT compiler. Does this code leak the
percpu private stack if JIT compilation fails after header allocation?

If bpf_jit_build_body() fails, the error path frees the header but does not
nullify the ro_header pointer. The subsequent cleanup block evaluates to false,
failing to free priv_stack_ptr. Since prog->jited remains 0, bpf_jit_free()
also skips freeing it.


kernel/bpf/core.c:bpf_jit_binary_pack_finalize() {
...
	ptr = bpf_arch_text_copy(ro_header, rw_header, rw_header->size);

	kvfree(rw_header);

	if (IS_ERR(ptr)) {
		bpf_prog_pack_free(ro_header, ro_header->size);
		return PTR_ERR(ptr);
	}
...
}

[Severity: High]
This is a pre-existing issue, but I spotted a potential memory corruption
and resource leak in the BPF core during JIT finalize. Can this error path
cause a system crash and leak modmem charges?

If bpf_arch_text_copy() fails, the size field in ro_header remains
uninitialized (for example, filled with breakpoint instructions by
bpf_fill_ill_insns()). Calling bpf_prog_pack_free() with this wild size
could corrupt the allocator.

Also, does this error path permanently leak the module memory charge by
returning without calling bpf_jit_uncharge_modmem(size)?

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