Re: [PATCH bpf-next 0/4] bpf: Disable private stacks for uprobe programs

[Jiri Olsa <olsajiri@gmail.com>]

On Wed, Nov 04, 2026 at 04:33:32AM +0000, Alexei Starovoitov wrote:
> On Tue, Nov 03, 2026 at 01:33 AM Jiri Olsa <jolsa@kernel.org> wrote:
> > As discussed in [1], there seems to be no known compatible fix for
> > private stack corruption in standard uprobes. This series leaves that
> > issue unchanged and adds the BPF_TRACE_UPROBE attach type for new
> > standard uprobe programs, allowing the kernel to identify them and
> > disable their private stacks.
> 
> New uapi to fix a bug is not a good tradeoff imo.
> The bug stays for every loader that doesn't set the new attach type.
> HyeongJun's tracer is one of those.
> BPF_TRACE_UPROBE is also the last attach type that fits into
> u64 allowed_attachs of the token.
> 
> > - disable private stacks for all KPROBE programs: protects uprobes,
> >   but may reject existing kprobe programs that rely on private stacks.
> 
> can we do that for all of them except kprobe.multi and kprobe.session ?
> A prog without attach type is either kprobe or uprobe.
> The kernel can't tell, so it gets the kernel stack.
> 
> Without the private stack the verifier sums the frames of a call chain.
> The limit is 2 Kbytes on x86-64 and arm64 now.
> 
> The options for standard uprobes:
> 
>   option                   untagged uprobes  what stops working
>   ------------------------  ----------------  ---------------------------
>   BPF_TRACE_UPROBE          still corrupted   uprobe and kprobe progs in
>                                               one prog array
>   reject them at attach     can't attach      uprobe progs with 64+ bytes
>                                               of stack
>   no private stack without  fixed             kprobe progs with a call
>   attach type                                 chain above the limit
> 
> Row 1: a prog array takes progs of one attach type only.
> With patch 3 SEC("uprobe") has the new type and SEC("kprobe") has 0.
> 
> Then no need for the new attach type, the feature probe and SEC_UPROBE.
> 
> PERF_EVENT_IOC_SET_BPF doesn't check the attach type.
> It can attach a kprobe.multi prog to a uprobe. Hence the 2nd hunk.

fwiw this will fail via perf_link (in bpf_prog_attach_check_attach_type),
so it's just the ioctl problem

> 
> Something like this (compile tested only, selftests are not built):
> 
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 935b163..9003330 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5706,6 +5706,15 @@ static enum priv_stack_mode bpf_enable_priv_stack(struct bpf_prog *prog)
>  	 */
>  	switch (prog->type) {
>  	case BPF_PROG_TYPE_KPROBE:
> +		/*
> +		 * Uprobe progs are preemptible and don't check for recursion.
> +		 * Two tasks can run the same prog on the same cpu.
> +		 * A prog without attach type is either kprobe or uprobe.
> +		 */
> +		if (prog->expected_attach_type != BPF_TRACE_KPROBE_MULTI &&
> +		    prog->expected_attach_type != BPF_TRACE_KPROBE_SESSION)
> +			return NO_PRIV_STACK;
> +		fallthrough;
>  	case BPF_PROG_TYPE_TRACEPOINT:
>  	case BPF_PROG_TYPE_PERF_EVENT:
>  	case BPF_PROG_TYPE_RAW_TRACEPOINT:
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 457d75e..f2d4f8b 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -11856,6 +11856,10 @@ static int __perf_event_set_bpf_prog(struct perf_event *event,
>  	if (prog->aux->kprobe_write_ctx && !is_uprobe)
>  		return -EINVAL;
> 
> +	/* PERF_EVENT_IOC_SET_BPF takes kprobe.multi progs too. */
> +	if (prog->aux->jits_use_priv_stack && is_uprobe)
> +		return -EINVAL;

should we also ban all kprobe.multi programs in here?

checking only jits_use_priv_stack on the entry program may miss a
private-stack tail-call target, like:

- load a kprobe.multi entry program that tail-calls and does not use
  a private stack

- load a private-stack kprobe.multi target and add it to the entry
  program’s prog array. Their expected attach types match

- attach the entry program to a uprobe with PERF_EVENT_IOC_SET_BPF.
  The current check sees that the entry has no private stack and allows
  the attachment

- when the uprobe fires, the entry tail-calls the target, which runs
  with its private stack

rejecting kprobe.multi and kprobe.session programs on uprobe events
would prevent this path

jirka


---
diff --git a/kernel/events/core.c b/kernel/events/core.c
index e3f87d5df922..8b288729d47c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11856,8 +11856,14 @@ static int __perf_event_set_bpf_prog(struct perf_event *event,
 	if (prog->aux->kprobe_write_ctx && !is_uprobe)
 		return -EINVAL;
 
-	/* PERF_EVENT_IOC_SET_BPF also accepts kprobe.multi progs. */
-	if (prog->aux->jits_use_priv_stack && is_uprobe)
+	/*
+	 * kprobe.multi/session programs may tail-call programs using a private
+	 * stack, even when the entry program does not use one.
+	 */
+	if (is_uprobe &&
+	    (prog->aux->jits_use_priv_stack ||
+	     prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI ||
+	     prog->expected_attach_type == BPF_TRACE_KPROBE_SESSION))
 		return -EINVAL;
 
 	if (is_tracepoint || is_syscall_tp) {