From: Jiri Olsa <olsajiri@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 5/9] bpf: Disable preemption in bpf_get_stackid
Date: Mon, 20 Jul 2026 22:31:25 +0200 [thread overview]
Message-ID: <al6FnX19vBr0Bpyt@krava> (raw)
In-Reply-To: <20260720090411.61E931F00A3A@smtp.kernel.org>
On Mon, Jul 20, 2026 at 09:04:10AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Incomplete fix for preemption vulnerability in stack helpers (__bpf_get_stack)
> --
>
> --- Patch [5]: [PATCH bpf-next 5/9] bpf: Disable preemption in bpf_get_stackid ---
> commit eb097d7647defa7379264dcdf95711bc573a419a
> Author: Jiri Olsa <jolsa@kernel.org>
>
> bpf: Disable preemption in bpf_get_stackid
>
> This commit adds preempt_disable() and preempt_enable() around the
> get_perf_callchain() call and trace buffer usage in bpf_get_stackid()
> to prevent the per-CPU trace entries buffer from being corrupted if the
> task is preempted.
>
> Closes: https://lore.kernel.org/bpf/20260206090653.1336687-2-chen.dylane@linux.dev/
>
> > diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
> > index 83efd5892d907..a64b14ffd1e8e 100644
> > --- a/kernel/bpf/stackmap.c
> > +++ b/kernel/bpf/stackmap.c
> > @@ -625,30 +625,37 @@ BPF_CALL_3(bpf_get_stackid, struct pt_regs *, regs, struct bpf_map *, map,
> > struct perf_callchain_entry *trace;
> > struct stackid stackid;
> > bool kernel = !user;
> > + int err = -EFAULT;
> > u32 max_depth;
> > - int err;
> >
> > if (unlikely(flags & ~(BPF_F_SKIP_FIELD_MASK | BPF_F_USER_STACK |
> > BPF_F_FAST_STACK_CMP | BPF_F_REUSE_STACKID)))
> > return -EINVAL;
> >
> > max_depth = stack_map_calculate_max_depth(map->value_size, elem_size, flags);
> > +
> > + preempt_disable();
> > trace = get_perf_callchain(regs, kernel, user, max_depth,
> > false, false, 0);
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does __bpf_get_stack() also
> need this preempt_disable() protection?
>
> __bpf_get_stack() has a similar pattern where it calls get_perf_callchain()
> or get_callchain_entry_for_task() and dereferences trace->ip via memcpy().
>
> While it uses rcu_read_lock() when may_fault is true, on CONFIG_PREEMPT_RCU
> kernels this does not prevent preemption.
>
> Could a preempting task trigger another stack trace on the same CPU before
> the memcpy() finishes, overwriting the per-CPU buffer in __bpf_get_stack()?
__bpf_get_stack is taken care of in the following patches
jirka
next prev parent reply other threads:[~2026-07-20 20:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 8:53 [PATCH bpf-next 0/9] bpf: Disable preemption in stack map code Jiri Olsa
2026-07-20 8:53 ` [PATCH bpf-next 1/9] bpf: Factor stackid_init function from __bpf_get_stackid Jiri Olsa
2026-07-20 8:53 ` [PATCH bpf-next 2/9] bpf: Factor stackid_fastpath " Jiri Olsa
2026-07-20 9:09 ` sashiko-bot
2026-07-20 20:31 ` Jiri Olsa
2026-07-20 8:53 ` [PATCH bpf-next 3/9] bpf: Factor stackid_new_bucket " Jiri Olsa
2026-07-20 9:01 ` sashiko-bot
2026-07-20 20:31 ` Jiri Olsa
2026-07-20 8:53 ` [PATCH bpf-next 4/9] bpf: Use stack id functions instead of __bpf_get_stackid Jiri Olsa
2026-07-20 8:53 ` [PATCH bpf-next 5/9] bpf: Disable preemption in bpf_get_stackid Jiri Olsa
2026-07-20 9:04 ` sashiko-bot
2026-07-20 20:31 ` Jiri Olsa [this message]
2026-07-20 8:53 ` [PATCH bpf-next 6/9] bpf: Factor callchain_store function from __bpf_get_stack Jiri Olsa
2026-07-20 9:07 ` sashiko-bot
2026-07-20 20:31 ` Jiri Olsa
2026-07-20 8:53 ` [PATCH bpf-next 7/9] bpf: Factor callchain_finalize " Jiri Olsa
2026-07-20 9:08 ` sashiko-bot
2026-07-20 20:31 ` Jiri Olsa
2026-07-20 8:53 ` [PATCH bpf-next 8/9] bpf: Remove trace_in argument " Jiri Olsa
2026-07-20 9:09 ` sashiko-bot
2026-07-20 20:31 ` Jiri Olsa
2026-07-20 8:53 ` [PATCH bpf-next 9/9] bpf: Disable preemption in __bpf_get_stack Jiri Olsa
2026-07-20 9:18 ` sashiko-bot
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=al6FnX19vBr0Bpyt@krava \
--to=olsajiri@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.