All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Saket Kumar Bhaskar" <skb99@linux.ibm.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v12 5/8] powerpc64/bpf: fix percpu private stack leak on JIT failure
Date: Tue, 18 Aug 2026 04:56:18 +0000	[thread overview]
Message-ID: <20260818045619.3174A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <97a39fe69332e2db95f2e653445c5b8c9adc205b.1787027080.git.skb99@linux.ibm.com>

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

Pre-existing issues:
- [High] Pre-existing error handling flaw in `bpf_jit_free()` leads to a double-free and use-after-free of the BPF binary pack if `bpf_jit_binary_pack_finalize()` fails.
- [High] The exact same per-CPU private stack leak fixed in this patch for PowerPC also exists in the ARM64 BPF JIT compiler.
--

--- Patch [5]: [PATCH v12 5/8] powerpc64/bpf: fix percpu private stack leak on JIT failure ---
commit 7f3490460ab3b86fd0696381ed6fb1a49e89ac48
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 38acef44c0979..b45fa80271068 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) {

[Severity: High]
This isn't a bug introduced by this patch, but does the arm64 BPF JIT have the
exact same leak this patch fixes?

Looking at bpf_int_jit_compile() in arch/arm64/net/bpf_jit_comp.c:

	out_off:
		if (!ro_header && priv_stack_ptr) {
			free_percpu(priv_stack_ptr);
			prog->aux->priv_stack_ptr = NULL;
		}

If JIT compilation fails late (e.g., validate_ctx fails), it jumps to the
out_free_hdr block which frees the header but doesn't set ro_header to NULL.
Execution then falls through to out_off. Since ro_header is non-NULL, it skips
freeing the stack. bpf_jit_free() also skips it because prog->jited is 0.

Should the arm64 code also be updated to use !prog->jited?


[Severity: High]
This is a pre-existing issue, but can ignoring the return value of
bpf_jit_binary_pack_finalize() in bpf_jit_free() cause a double-free?

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);
		// ...
	}
	hdr = bpf_jit_binary_pack_hdr(fp);
	bpf_jit_binary_pack_free(hdr, NULL);

If bpf_jit_binary_pack_finalize() fails, it frees ro_header and returns an
error:

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);
	}
	...
}

Because bpf_jit_free() ignores this return value, it immediately re-fetches
the freed header and calls bpf_jit_binary_pack_free() again.

Does this lead to a use-after-free read of the garbage size and a double free
of the pack?

>  			fp->aux->priv_stack_ptr = NULL;
>  			free_percpu(priv_stack_ptr);
>  		}

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

  reply	other threads:[~2026-08-18  4:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1787027080.git.skb99@linux.ibm.com>
2026-08-18  4:43 ` [PATCH v12 1/8] powerpc/bpf: fix buffer overflow in JIT for large BPF programs Saket Kumar Bhaskar
2026-08-18  5:00   ` sashiko-bot
2026-08-18  4:43 ` [PATCH v12 2/8] powerpc/bpf: fix alignment of long branch trampoline address Saket Kumar Bhaskar
2026-08-18  5:45   ` bot+bpf-ci
2026-08-18  4:43 ` [PATCH v12 3/8] powerpc/bpf: Move out dummy_tramp_addr after Long branch stub Saket Kumar Bhaskar
2026-08-18  5:32   ` bot+bpf-ci
2026-08-18  4:43 ` [PATCH v12 4/8] powerpc64/bpf: fix compare instruction emitted for tailcall Saket Kumar Bhaskar
2026-08-18  4:43 ` [PATCH v12 5/8] powerpc64/bpf: fix percpu private stack leak on JIT failure Saket Kumar Bhaskar
2026-08-18  4:56   ` sashiko-bot [this message]
2026-08-18  4:43 ` [PATCH v12 6/8] selftests/bpf: Fixing powerpc JIT disassembly failure Saket Kumar Bhaskar
2026-08-18  5:32   ` bot+bpf-ci
2026-08-18  4:43 ` [PATCH v12 7/8] selftests/bpf: Enable verifier selftest for powerpc64 Saket Kumar Bhaskar
2026-08-18  4:43 ` [PATCH v12 8/8] selftests/bpf: Add tailcall " Saket Kumar Bhaskar
2026-08-18  5:32   ` bot+bpf-ci

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=20260818045619.3174A1F000E9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.