From: sashiko-bot@kernel.org
To: "Junseo Lim" <zirajs7@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf v2] bpf: keep trampoline progs alive until image release
Date: Thu, 20 Aug 2026 02:42:37 +0000 [thread overview]
Message-ID: <20260820024237.B27A21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260820022831.18601-1-zirajs7@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The patch restricts the `bpf_tramp_image` program reference counting fix to `CONFIG_PREEMPTION=y`, leaving `CONFIG_PREEMPTION=n` kernels vulnerable to a Use-After-Free if `bpf_trampoline_update()` fails during program unlinking.
--
--- Patch [1]: [PATCH bpf v2] bpf: keep trampoline progs alive until image release ---
commit e97f38fbbba7062b73e2785973928c70f36f1661
Author: Junseo Lim <zirajs7@gmail.com>
bpf: keep trampoline progs alive until image release
arch_prepare_bpf_trampoline() embeds program pointers in the generated
image. After bpf_trampoline_update() replaces the image,
bpf_tramp_image_put() can keep the old image executable past a normal RCU
grace period, allowing a detached non-sleepable prog to be freed before a
preempted task finishes, leading to a use-after-free. This patch keeps
image-local prog refs and drops them from bpf_tramp_image_free().
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -1376,6 +1376,11 @@ struct bpf_tramp_image {
> struct rcu_head rcu;
> struct work_struct work;
> };
> +#ifdef CONFIG_PREEMPTION
> + /* Programs called from this image must outlive deferred image freeing. */
> + struct bpf_prog *progs[BPF_MAX_TRAMP_LINKS];
> + int nr_progs;
> +#endif
> };
[ ... ]
> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> --- a/kernel/bpf/trampoline.c
> +++ b/kernel/bpf/trampoline.c
> @@ -529,8 +529,36 @@ bpf_trampoline_get_progs(const struct bpf_trampoline *tr, int *total, bool *ip_a
> return tnodes;
> }
>
> +static void bpf_tramp_image_get_progs(struct bpf_tramp_image *im,
> + struct bpf_tramp_nodes *tnodes)
> +{
> +#ifdef CONFIG_PREEMPTION
^^^^
[Severity: High]
This is a pre-existing issue, but does restricting this reference counting to
CONFIG_PREEMPTION=y leave CONFIG_PREEMPTION=n kernels vulnerable to a
use-after-free if bpf_trampoline_update() fails during program unlinking?
If a user detaches a BPF tracing program, bpf_tracing_link_release() calls
__bpf_trampoline_unlink_prog(), which removes the program from the trampoline
list and calls bpf_trampoline_update().
If bpf_trampoline_update() fails (for example, due to -ENOMEM in
bpf_tramp_image_alloc()), the error is absorbed by a WARN_ON_ONCE. The link's
reference to the program is subsequently dropped, and the program is freed.
However, because the update failed, the old executable image remains active
and continues to execute the embedded pointers to the freed program memory.
Could the CONFIG_PREEMPTION ifdef guards be removed so that the image always
holds references to its programs, preventing the use-after-free for
CONFIG_PREEMPTION=n kernels as well?
> + int i, kind;
> +
> + for (kind = 0; kind < BPF_TRAMP_MAX; kind++)
> + for (i = 0; i < tnodes[kind].nr_nodes; i++) {
> + struct bpf_prog *prog = tnodes[kind].nodes[i]->link->prog;
> +
> + bpf_prog_inc(prog);
> + im->progs[im->nr_progs++] = prog;
> + }
> +#endif
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260820022831.18601-1-zirajs7@gmail.com?part=1
next prev parent reply other threads:[~2026-08-20 2:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 2:28 [PATCH bpf v2] bpf: keep trampoline progs alive until image release Junseo Lim
2026-08-20 2:42 ` sashiko-bot [this message]
2026-08-20 3:35 ` 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=20260820024237.B27A21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zirajs7@gmail.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