From: sashiko-bot@kernel.org
To: "Saket Kumar Bhaskar" <skb99@linux.ibm.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v11 8/8] powerpc64/bpf: fix percpu private stack leak on JIT failure
Date: Fri, 07 Aug 2026 13:04:58 +0000 [thread overview]
Message-ID: <20260807130459.1804F1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <6bbf4249e47dc14ac65d72c304bf9335cf10b206.1786099877.git.skb99@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] In `bpf_jit_binary_pack_finalize()`, if `bpf_arch_text_copy()` fails, it uses uninitialized `ro_header->size` to free the pack (causing bitmap corruption) and fails to uncharge modmem.
- [Critical] If `bpf_jit_binary_pack_finalize()` fails during `bpf_jit_free()`, the JIT memory pack is double-freed.
- [High] The ARM64 BPF JIT compiler has the exact same percpu private stack memory leak on failure paths that this patch fixes for PowerPC.
--
--- Patch [8]: [PATCH v11 8/8] powerpc64/bpf: fix percpu private stack leak on JIT failure ---
commit e1be4be6e638db0714dd1f4ef6a5f98e6f888db6
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 at out_addrs only when the image buffer was never
allocated.
Closes: 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 2cc1124ed5303..395f1458db2e6 100644
> --- a/arch/powerpc/net/bpf_jit_comp.c
> +++ b/arch/powerpc/net/bpf_jit_comp.c
> @@ -404,7 +404,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);
> }
[Severity: High]
This isn't a bug introduced by this patch, but the ARM64 BPF JIT compiler
has the exact same percpu private stack memory leak on failure paths that
this patch addresses for PowerPC.
In 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;
}
On failure paths jumping from out_free_hdr, ro_header is not NULL, causing
the percpu stack free to be skipped. Could this also exhaust percpu memory
on ARM64?
[Severity: Critical]
This is a pre-existing issue, but if bpf_jit_binary_pack_finalize() fails
during bpf_jit_free(), does this double-free the JIT memory pack?
In arch/powerpc/net/bpf_jit_comp.c:bpf_jit_free():
if (jit_data) {
bpf_jit_binary_pack_finalize(jit_data->fhdr,
jit_data->hdr);
kvfree(jit_data->addrs);
kfree(jit_data);
}
hdr = bpf_jit_binary_pack_hdr(fp);
bpf_jit_binary_pack_free(hdr, NULL);
If jit_subprogs() aborts early and calls bpf_jit_free() on subprograms,
bpf_jit_binary_pack_finalize() is called. If its internal text copy fails,
it internally frees ro_header. However, the return value of
bpf_jit_binary_pack_finalize() is ignored here, and bpf_jit_binary_pack_free()
is called again, which seems to double-free the same pack structure.
The same pattern appears to exist in arch/x86/net/bpf_jit_comp.c:bpf_jit_free()
as well.
[Severity: Critical]
This is a pre-existing issue, but does bpf_jit_binary_pack_finalize() use
uninitialized memory if bpf_arch_text_copy() fails?
In kernel/bpf/core.c:bpf_jit_binary_pack_finalize():
if (IS_ERR(ptr)) {
bpf_prog_pack_free(ro_header, ro_header->size);
return PTR_ERR(ptr);
}
If bpf_arch_text_copy() fails, ro_header->size has not been initialized.
Could this clear arbitrary memory regions in the shared pack allocator bitmap
and permanently leak the module memory charge since bpf_jit_uncharge_modmem()
is missing on this error path?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1786099877.git.skb99@linux.ibm.com?part=8
prev parent reply other threads:[~2026-08-07 13:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1786099877.git.skb99@linux.ibm.com>
2026-08-07 11:42 ` [PATCH v11 1/8] powerpc/bpf: fix alignment of long branch trampoline address Saket Kumar Bhaskar
2026-08-07 12:00 ` sashiko-bot
2026-08-07 11:42 ` [PATCH v11 2/8] powerpc/bpf: Move out dummy_tramp_addr after Long branch stub Saket Kumar Bhaskar
2026-08-07 11:42 ` [PATCH v11 3/8] selftests/bpf: Fixing powerpc JIT disassembly failure Saket Kumar Bhaskar
2026-08-07 12:59 ` bot+bpf-ci
2026-08-07 11:42 ` [PATCH v11 4/8] selftests/bpf: Enable verifier selftest for powerpc64 Saket Kumar Bhaskar
2026-08-07 11:42 ` [PATCH v11 5/8] powerpc64/bpf: fix compare instruction emitted for tailcall Saket Kumar Bhaskar
2026-08-07 11:42 ` [PATCH v11 6/8] selftests/bpf: Add tailcall verifier selftest for powerpc64 Saket Kumar Bhaskar
2026-08-07 12:32 ` sashiko-bot
2026-08-07 11:42 ` [PATCH v11 7/8] powerpc/bpf: fix buffer overflow in JIT for large BPF programs Saket Kumar Bhaskar
2026-08-07 12:41 ` sashiko-bot
2026-08-07 11:42 ` [PATCH v11 8/8] powerpc64/bpf: fix percpu private stack leak on JIT failure Saket Kumar Bhaskar
2026-08-07 13:04 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260807130459.1804F1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=skb99@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox