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

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

[Jiri Olsa]

hi,
uprobe programs can be preempted and re-entered on the same CPU. Since
the private stack is shared per program and CPU, a nested invocation can
overwrite the preempted invocation's stack.

Uprobe multi and session programs have attach types that let the kernel
identify them, so this series disables their private stacks.

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.

Other possible fixes for standard uprobes include:

- disable private stacks for all KPROBE programs: protects uprobes,
  but may reject existing kprobe programs that rely on private stacks.

- reject untagged programs on uprobe events: protects uprobes, but
  breaks legacy loaders that attach standard uprobes without the new
  attach type.

- disable preemption while the uprobe program runs: may prevent overlapping
  invocations on the same CPU, but cannot be used for sleepable uprobe
  programs and may increase latency

We can pick the uprobe-multi fix and keep discussing standard uprobes fix,
I'm open to other suggestions.

thanks,
jirka


[1] https://lore.kernel.org/bpf/20260822225444.2774461-1-simon@swine.de/
---
Jiri Olsa (4):
      bpf: Disable private stack for uprobe programs
      bpf: Add BPF_TRACE_UPROBE attach type
      libbpf: Detect BPF_TRACE_UPROBE support
      selftests/bpf: Verify classic uprobe attach types

 Documentation/bpf/libbpf/program_types.rst      |  8 +++++---
 include/uapi/linux/bpf.h                        |  1 +
 kernel/bpf/verifier.c                           |  6 ++++++
 kernel/events/core.c                            |  3 +++
 tools/include/uapi/linux/bpf.h                  |  1 +
 tools/lib/bpf/features.c                        | 22 ++++++++++++++++++++++
 tools/lib/bpf/libbpf.c                          | 21 +++++++++++++++------
 tools/lib/bpf/libbpf_internal.h                 |  2 ++
 tools/testing/selftests/bpf/prog_tests/uprobe.c |  4 ++++
 9 files changed, 59 insertions(+), 9 deletions(-)

[PATCH bpf-next 1/4] bpf: Disable private stack for uprobe programs

[Jiri Olsa]

Uprobe programs can be preempted, allowing another task to run the same
program on the same CPU. Since the private stack is per program and CPU,
the new invocation can reuse and overwrite the preempted invocation's
stack.

Disable private stacks for uprobe multi programs. Fixing the issue for
standard uprobes requires additional changes and will be handled separately.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 kernel/bpf/verifier.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 935b163f81e4..a9c6a4b8eecc 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5706,6 +5706,11 @@ static enum priv_stack_mode bpf_enable_priv_stack(struct bpf_prog *prog)
 	 */
 	switch (prog->type) {
 	case BPF_PROG_TYPE_KPROBE:
+		/* Disable private stack for uprobe programs. */
+		if (prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI ||
+		    prog->expected_attach_type == BPF_TRACE_UPROBE_SESSION)
+			return NO_PRIV_STACK;
+		fallthrough;
 	case BPF_PROG_TYPE_TRACEPOINT:
 	case BPF_PROG_TYPE_PERF_EVENT:
 	case BPF_PROG_TYPE_RAW_TRACEPOINT:
-- 
2.43.0

[PATCH bpf-next 2/4] bpf: Add BPF_TRACE_UPROBE attach type

[Jiri Olsa]

Add an expected attach type for classic uprobe programs.
Reject attaching these programs to non-uprobe perf events
and disable the private stack for them.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 include/uapi/linux/bpf.h       | 1 +
 kernel/bpf/verifier.c          | 3 ++-
 kernel/events/core.c           | 3 +++
 tools/include/uapi/linux/bpf.h | 1 +
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 62de0919db72..3c8a75b4c744 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1206,6 +1206,7 @@ enum bpf_attach_type {
 	BPF_TRACE_FENTRY_MULTI,
 	BPF_TRACE_FEXIT_MULTI,
 	BPF_TRACE_FSESSION_MULTI,
+	BPF_TRACE_UPROBE,
 	__MAX_BPF_ATTACH_TYPE
 };
 
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index a9c6a4b8eecc..7c941e009a33 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5707,7 +5707,8 @@ static enum priv_stack_mode bpf_enable_priv_stack(struct bpf_prog *prog)
 	switch (prog->type) {
 	case BPF_PROG_TYPE_KPROBE:
 		/* Disable private stack for uprobe programs. */
-		if (prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI ||
+		if (prog->expected_attach_type == BPF_TRACE_UPROBE ||
+		    prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI ||
 		    prog->expected_attach_type == BPF_TRACE_UPROBE_SESSION)
 			return NO_PRIV_STACK;
 		fallthrough;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 457d75ea7142..016d479467ed 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11835,6 +11835,9 @@ static int __perf_event_set_bpf_prog(struct perf_event *event,
 	    (is_syscall_tp && prog->type != BPF_PROG_TYPE_TRACEPOINT))
 		return -EINVAL;
 
+	if (prog->expected_attach_type == BPF_TRACE_UPROBE && !is_uprobe)
+		return -EINVAL;
+
 	if (prog->type == BPF_PROG_TYPE_KPROBE && prog->sleepable && !is_uprobe)
 		/* only uprobe programs are allowed to be sleepable */
 		return -EINVAL;
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 62de0919db72..3c8a75b4c744 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -1206,6 +1206,7 @@ enum bpf_attach_type {
 	BPF_TRACE_FENTRY_MULTI,
 	BPF_TRACE_FEXIT_MULTI,
 	BPF_TRACE_FSESSION_MULTI,
+	BPF_TRACE_UPROBE,
 	__MAX_BPF_ATTACH_TYPE
 };
 
-- 
2.43.0

Re: [PATCH bpf-next 2/4] bpf: Add BPF_TRACE_UPROBE attach type

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] bpf: private stack remains enabled for uprobes without BPF_TRACE_UPROBE
- [Medium] bpf: missing BPF_TRACE_UPROBE validation at prog load and attach
--

commit c83a6cf6c87c8d327256fad738b73343332bf238
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Add BPF_TRACE_UPROBE attach type

This commit adds the BPF_TRACE_UPROBE expected attach type for classic uprobe
programs, disables the private stack for programs using it in the verifier,
and rejects attaching them to non-uprobe perf events.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index a9c6a4b8eecce..7c941e009a337 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5707,7 +5707,8 @@ static enum priv_stack_mode bpf_enable_priv_stack(struct bpf_prog *prog)
>  	switch (prog->type) {
>  	case BPF_PROG_TYPE_KPROBE:
>  		/* Disable private stack for uprobe programs. */
> -		if (prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI ||
> +		if (prog->expected_attach_type == BPF_TRACE_UPROBE ||
> +		    prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI ||
>  		    prog->expected_attach_type == BPF_TRACE_UPROBE_SESSION)
>  			return NO_PRIV_STACK;
>  		fallthrough;

[Severity: High]
Can classic uprobe programs still end up with a private stack enabled and
corrupt per-CPU stack state when expected_attach_type is 0?

Classic uprobe programs run via __uprobe_perf_func() ->
bpf_prog_run_array_uprobe() in preemptible (and sleepable when
prog->sleepable is set) context with migrate_disable() and without any
per-CPU recursion guard:

include/linux/bpf.h:bpf_prog_run_array_uprobe() {
	...
	migrate_disable();
	while ((prog = READ_ONCE(item->prog))) {
		if (!prog->sleepable)
			rcu_read_lock();

		run_ctx.bpf_cookie = item->bpf_cookie;
		ret &= run_prog(prog, ctx);
		item++;

		if (!prog->sleepable)
			rcu_read_unlock();
	}
	migrate_enable();
	...
}

If a BPF_PROG_TYPE_KPROBE program with a stack depth of at least
BPF_PRIV_STACK_MIN_SIZE is loaded with expected_attach_type == 0 (including
programs with uprobe-only properties such as prog->sleepable or
prog->aux->kprobe_write_ctx), bpf_enable_priv_stack() still returns
PRIV_STACK_ADAPTIVE.

Even with libbpf updated in the follow-up commit to pass BPF_TRACE_UPROBE,
__perf_event_set_bpf_prog() still permits attaching a BPF_PROG_TYPE_KPROBE
program with expected_attach_type == 0 and prog->aux->jits_use_priv_stack
set to a uprobe perf event. If one task executing the uprobe on a CPU is
preempted or sleeps on a page fault and another task on the same CPU hits the
same uprobe, both tasks will share prog->aux->priv_stack_ptr and overwrite
each other's stack frames.

Should bpf_enable_priv_stack() also check prog->sleepable and
prog->aux->kprobe_write_ctx, and should __perf_event_set_bpf_prog() reject
attaching a program with prog->aux->jits_use_priv_stack to a uprobe perf
event?

> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 457d75ea71420..016d479467edc 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -11835,6 +11835,9 @@ static int __perf_event_set_bpf_prog(struct perf_event *event,
>  	    (is_syscall_tp && prog->type != BPF_PROG_TYPE_TRACEPOINT))
>  		return -EINVAL;
>  
> +	if (prog->expected_attach_type == BPF_TRACE_UPROBE && !is_uprobe)
> +		return -EINVAL;
> +
>  	if (prog->type == BPF_PROG_TYPE_KPROBE && prog->sleepable && !is_uprobe)
>  		/* only uprobe programs are allowed to be sleepable */
>  		return -EINVAL;

[Severity: Medium]
What happens if a non-kprobe program is loaded with BPF_TRACE_UPROBE, or if a
kprobe program with BPF_TRACE_UPROBE is attached via BPF_LINK_CREATE with a
mismatched attach_type?

In kernel/bpf/syscall.c, bpf_prog_load_check_attach() does not restrict
BPF_TRACE_UPROBE to BPF_PROG_TYPE_KPROBE. If a BPF_PROG_TYPE_PERF_EVENT
program is loaded with expected_attach_type == BPF_TRACE_UPROBE and attached
to a non-tracing perf event, __perf_event_set_bpf_prog() returns early before
reaching the new check:

kernel/events/core.c:__perf_event_set_bpf_prog() {
	if (event->state <= PERF_EVENT_STATE_REVOKED)
		return -ENODEV;

	if (!perf_event_is_tracing(event))
		return perf_event_set_bpf_handler(event, prog, bpf_cookie);
	...
	if (prog->expected_attach_type == BPF_TRACE_UPROBE && !is_uprobe)
		return -EINVAL;
}

Additionally, in kernel/bpf/syscall.c, bpf_prog_attach_check_attach_type()
validates BPF_TRACE_KPROBE_MULTI, BPF_TRACE_KPROBE_SESSION,
BPF_TRACE_UPROBE_MULTI, and BPF_TRACE_UPROBE_SESSION under
BPF_PROG_TYPE_KPROBE, but does not check that prog->expected_attach_type ==
BPF_TRACE_UPROBE requires attach_type == BPF_PERF_EVENT:

kernel/bpf/syscall.c:bpf_prog_attach_check_attach_type() {
	...
	case BPF_PROG_TYPE_KPROBE:
		if (prog->expected_attach_type == BPF_TRACE_KPROBE_MULTI &&
		    attach_type != BPF_TRACE_KPROBE_MULTI)
			return -EINVAL;
		if (prog->expected_attach_type == BPF_TRACE_KPROBE_SESSION &&
		    attach_type != BPF_TRACE_KPROBE_SESSION)
			return -EINVAL;
		if (prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI &&
		    attach_type != BPF_TRACE_UPROBE_MULTI)
			return -EINVAL;
		if (prog->expected_attach_type == BPF_TRACE_UPROBE_SESSION &&
		    attach_type != BPF_TRACE_UPROBE_SESSION)
			return -EINVAL;
}

If a BPF_PROG_TYPE_KPROBE program with expected_attach_type ==
BPF_TRACE_UPROBE is passed to link_create() with attach_type set to
BPF_TRACE_KPROBE_MULTI or BPF_TRACE_UPROBE_MULTI, it bypasses
bpf_prog_attach_check_attach_type() and returns -EOPNOTSUPP instead of
-EINVAL when CONFIG_FPROBE or CONFIG_UPROBES is disabled or on 32-bit
architectures.

Should bpf_prog_load_check_attach() and bpf_prog_attach_check_attach_type()
also validate BPF_TRACE_UPROBE?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103093400.112178-1-jolsa@kernel.org?part=2

[PATCH bpf-next 3/4] libbpf: Detect BPF_TRACE_UPROBE support

[Jiri Olsa]

Probe whether the kernel accepts BPF_TRACE_UPROBE as the expected
attach type for KPROBE programs. If it does not, load uprobe and
uretprobe programs with zero expected attach type.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 Documentation/bpf/libbpf/program_types.rst |  8 +++++---
 tools/lib/bpf/features.c                   | 22 ++++++++++++++++++++++
 tools/lib/bpf/libbpf.c                     | 21 +++++++++++++++------
 tools/lib/bpf/libbpf_internal.h            |  2 ++
 4 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/Documentation/bpf/libbpf/program_types.rst b/Documentation/bpf/libbpf/program_types.rst
index 3a07ce3b7f79..1c4424aab601 100644
--- a/Documentation/bpf/libbpf/program_types.rst
+++ b/Documentation/bpf/libbpf/program_types.rst
@@ -90,15 +90,15 @@ described in more detail in the footnotes.
 |                                           |                                        | ``ksyscall+`` [#ksyscall]_       |           |
 +                                           +                                        +----------------------------------+-----------+
 |                                           |                                        |  ``kretsyscall+`` [#ksyscall]_   |           |
-+                                           +                                        +----------------------------------+-----------+
-|                                           |                                        | ``uprobe+`` [#uprobe]_           |           |
++                                           +----------------------------------------+----------------------------------+-----------+
+|                                           | ``BPF_TRACE_UPROBE``                   | ``uprobe+`` [#uprobe]_           |           |
 +                                           +                                        +----------------------------------+-----------+
 |                                           |                                        | ``uprobe.s+`` [#uprobe]_         | Yes       |
 +                                           +                                        +----------------------------------+-----------+
 |                                           |                                        | ``uretprobe+`` [#uprobe]_        |           |
 +                                           +                                        +----------------------------------+-----------+
 |                                           |                                        | ``uretprobe.s+`` [#uprobe]_      | Yes       |
-+                                           +                                        +----------------------------------+-----------+
++                                           +----------------------------------------+----------------------------------+-----------+
 |                                           |                                        | ``usdt+`` [#usdt]_               |           |
 +                                           +                                        +----------------------------------+-----------+
 |                                           |                                        | ``usdt.s+`` [#usdt]_             | Yes       |
@@ -239,6 +239,8 @@ described in more detail in the footnotes.
              non-negative integer.
 .. [#ksyscall] The ``ksyscall`` attach format is ``ksyscall/<syscall>``.
 .. [#uprobe] The ``uprobe`` attach format is ``uprobe[.s]/<path>:<function>[+<offset>]``.
+             libbpf uses ``BPF_TRACE_UPROBE`` for these sections when the kernel supports it;
+             otherwise it loads them with an unspecified attach type for compatibility.
 .. [#upmul] The ``uprobe.multi`` attach format is ``uprobe.multi[.s]/<path>:<function-pattern>``
             where ``function-pattern`` supports ``*`` and ``?`` wildcards.
 .. [#usdt] The ``usdt`` attach format is ``usdt/<path>:<provider>:<name>``.
diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
index adb5d2e7fdfa..175d96c0a501 100644
--- a/tools/lib/bpf/features.c
+++ b/tools/lib/bpf/features.c
@@ -318,6 +318,24 @@ static int probe_kern_exp_attach_type(int token_fd)
 	return probe_fd(fd);
 }
 
+static int probe_kern_uprobe_attach_type(int token_fd)
+{
+	LIBBPF_OPTS(bpf_prog_load_opts, opts,
+		.expected_attach_type = BPF_TRACE_UPROBE,
+		.token_fd = token_fd,
+		.prog_flags = token_fd ? BPF_F_TOKEN_FD : 0,
+	);
+	struct bpf_insn insns[] = {
+		BPF_MOV64_IMM(BPF_REG_0, 0),
+		BPF_EXIT_INSN(),
+	};
+	int fd;
+
+	fd = bpf_prog_load(BPF_PROG_TYPE_KPROBE, NULL, "GPL", insns,
+			   ARRAY_SIZE(insns), &opts);
+	return probe_fd(fd);
+}
+
 static int probe_kern_probe_read_kernel(int token_fd)
 {
 	LIBBPF_OPTS(bpf_prog_load_opts, opts,
@@ -761,6 +779,10 @@ static struct kern_feature_desc {
 		"BPF_PROG_LOAD expected_attach_type attribute",
 		probe_kern_exp_attach_type,
 	},
+	[FEAT_UPROBE_ATTACH_TYPE] = {
+		"BPF_TRACE_UPROBE expected attach type",
+		probe_kern_uprobe_attach_type,
+	},
 	[FEAT_PROBE_READ_KERN] = {
 		"bpf_probe_read_kernel() helper", probe_kern_probe_read_kernel,
 	},
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 02e75b183ed0..1f1c911fa295 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -139,6 +139,7 @@ static const char * const attach_type_name[] = {
 	[BPF_TRACE_FENTRY_MULTI]	= "trace_fentry_multi",
 	[BPF_TRACE_FEXIT_MULTI]		= "trace_fexit_multi",
 	[BPF_TRACE_FSESSION_MULTI]	= "trace_fsession_multi",
+	[BPF_TRACE_UPROBE]		= "trace_uprobe",
 };
 
 static const char * const link_type_name[] = {
@@ -424,6 +425,8 @@ enum sec_def_flags {
 	SEC_XDP_FRAGS = 16,
 	/* Setup proper attach type for usdt probes. */
 	SEC_USDT = 32,
+	/* Set BPF_TRACE_UPROBE when the kernel supports it. */
+	SEC_UPROBE = 64,
 };
 
 struct bpf_sec_def {
@@ -8398,6 +8401,12 @@ static int libbpf_prepare_prog_load(struct bpf_program *prog,
 	if ((def & SEC_EXP_ATTACH_OPT) && !kernel_supports(prog->obj, FEAT_EXP_ATTACH_TYPE))
 		opts->expected_attach_type = 0;
 
+	/* set uprobe attach_type if supported */
+	if ((def & SEC_UPROBE) && kernel_supports(prog->obj, FEAT_UPROBE_ATTACH_TYPE)) {
+		prog->expected_attach_type = BPF_TRACE_UPROBE;
+		opts->expected_attach_type = BPF_TRACE_UPROBE;
+	}
+
 	/* special check for usdt to use uprobe_multi link */
 	if ((def & SEC_USDT) && kernel_supports(prog->obj, FEAT_UPROBE_MULTI_LINK)) {
 		/* for BPF_TRACE_UPROBE_MULTI, user might want to query expected_attach_type
@@ -10842,11 +10851,11 @@ static const struct bpf_sec_def section_defs[] = {
 	SEC_DEF("sk_reuseport/migrate",	SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, SEC_ATTACHABLE),
 	SEC_DEF("sk_reuseport",		SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT, SEC_ATTACHABLE),
 	SEC_DEF("kprobe+",		KPROBE,	0, SEC_NONE, attach_kprobe),
-	SEC_DEF("uprobe+",		KPROBE,	0, SEC_NONE, attach_uprobe),
-	SEC_DEF("uprobe.s+",		KPROBE,	0, SEC_SLEEPABLE, attach_uprobe),
+	SEC_DEF("uprobe+",		KPROBE,	0, SEC_UPROBE, attach_uprobe),
+	SEC_DEF("uprobe.s+",		KPROBE,	0, SEC_UPROBE | SEC_SLEEPABLE, attach_uprobe),
 	SEC_DEF("kretprobe+",		KPROBE, 0, SEC_NONE, attach_kprobe),
-	SEC_DEF("uretprobe+",		KPROBE, 0, SEC_NONE, attach_uprobe),
-	SEC_DEF("uretprobe.s+",		KPROBE, 0, SEC_SLEEPABLE, attach_uprobe),
+	SEC_DEF("uretprobe+",		KPROBE, 0, SEC_UPROBE, attach_uprobe),
+	SEC_DEF("uretprobe.s+",		KPROBE, 0, SEC_UPROBE | SEC_SLEEPABLE, attach_uprobe),
 	SEC_DEF("kprobe.multi+",	KPROBE,	BPF_TRACE_KPROBE_MULTI, SEC_NONE, attach_kprobe_multi),
 	SEC_DEF("kretprobe.multi+",	KPROBE,	BPF_TRACE_KPROBE_MULTI, SEC_NONE, attach_kprobe_multi),
 	SEC_DEF("kprobe.session+",	KPROBE,	BPF_TRACE_KPROBE_SESSION, SEC_NONE, attach_kprobe_session),
@@ -10858,8 +10867,8 @@ static const struct bpf_sec_def section_defs[] = {
 	SEC_DEF("uprobe.session.s+",	KPROBE,	BPF_TRACE_UPROBE_SESSION, SEC_SLEEPABLE, attach_uprobe_multi),
 	SEC_DEF("ksyscall+",		KPROBE,	0, SEC_NONE, attach_ksyscall),
 	SEC_DEF("kretsyscall+",		KPROBE, 0, SEC_NONE, attach_ksyscall),
-	SEC_DEF("usdt+",		KPROBE,	0, SEC_USDT, attach_usdt),
-	SEC_DEF("usdt.s+",		KPROBE,	0, SEC_USDT | SEC_SLEEPABLE, attach_usdt),
+	SEC_DEF("usdt+",		KPROBE,	0, SEC_USDT | SEC_UPROBE, attach_usdt),
+	SEC_DEF("usdt.s+",		KPROBE,	0, SEC_USDT | SEC_UPROBE | SEC_SLEEPABLE, attach_usdt),
 	SEC_DEF("tc/ingress",		SCHED_CLS, BPF_TCX_INGRESS, SEC_NONE), /* alias for tcx */
 	SEC_DEF("tc/egress",		SCHED_CLS, BPF_TCX_EGRESS, SEC_NONE),  /* alias for tcx */
 	SEC_DEF("tcx/ingress",		SCHED_CLS, BPF_TCX_INGRESS, SEC_NONE),
diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_internal.h
index e90b5336bac0..d510f9184df6 100644
--- a/tools/lib/bpf/libbpf_internal.h
+++ b/tools/lib/bpf/libbpf_internal.h
@@ -366,6 +366,8 @@ enum kern_feature_id {
 	FEAT_ARRAY_MMAP,
 	/* kernel support for expected_attach_type in BPF_PROG_LOAD */
 	FEAT_EXP_ATTACH_TYPE,
+	/* BPF_TRACE_UPROBE expected attach type for KPROBE programs */
+	FEAT_UPROBE_ATTACH_TYPE,
 	/* bpf_probe_read_{kernel,user}[_str] helpers */
 	FEAT_PROBE_READ_KERN,
 	/* BPF_PROG_BIND_MAP is supported */
-- 
2.43.0

Re: [PATCH bpf-next 3/4] libbpf: Detect BPF_TRACE_UPROBE support

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] libbpf: broken BPF_TRACE_UPROBE detection in probe_kern_uprobe_attach_type()
--

commit daaaf792d9bbc9ce6b848daf8f14739d2eddbab7
Author: Jiri Olsa <jolsa@kernel.org>

libbpf: Detect BPF_TRACE_UPROBE support

This commit probes whether the kernel supports BPF_TRACE_UPROBE as the
expected attach type for BPF_PROG_TYPE_KPROBE programs and sets it for
uprobe, uretprobe, and usdt sections when supported.

> diff --git a/tools/lib/bpf/features.c b/tools/lib/bpf/features.c
> index adb5d2e7fdfa2..175d96c0a5012 100644
> --- a/tools/lib/bpf/features.c
> +++ b/tools/lib/bpf/features.c
> @@ -318,6 +318,24 @@ static int probe_kern_exp_attach_type(int token_fd)
>  	return probe_fd(fd);
>  }
>  
> +static int probe_kern_uprobe_attach_type(int token_fd)
> +{
> +	LIBBPF_OPTS(bpf_prog_load_opts, opts,
> +		.expected_attach_type = BPF_TRACE_UPROBE,
> +		.token_fd = token_fd,
> +		.prog_flags = token_fd ? BPF_F_TOKEN_FD : 0,
> +	);
> +	struct bpf_insn insns[] = {
> +		BPF_MOV64_IMM(BPF_REG_0, 0),
> +		BPF_EXIT_INSN(),
> +	};
> +	int fd;
> +
> +	fd = bpf_prog_load(BPF_PROG_TYPE_KPROBE, NULL, "GPL", insns,
> +			   ARRAY_SIZE(insns), &opts);
> +	return probe_fd(fd);
> +}

[Severity: Medium]
Does probe_kern_uprobe_attach_type() actually detect whether the running
kernel supports BPF_TRACE_UPROBE?

In kernel/bpf/syscall.c, bpf_prog_load() does not reject
attr->expected_attach_type >= __MAX_BPF_ATTACH_TYPE, and
bpf_prog_load_check_attach() has no case for BPF_PROG_TYPE_KPROBE, so it
falls through to the default branch and returns 0:

kernel/bpf/syscall.c:bpf_prog_load_check_attach() {
    ...
	case BPF_PROG_TYPE_SYSCALL:
	case BPF_PROG_TYPE_EXT:
		if (expected_attach_type)
			return -EINVAL;
		fallthrough;
	default:
		return 0;
	}
}

Because BPF_PROG_LOAD has accepted any expected_attach_type value for
BPF_PROG_TYPE_KPROBE since Linux 4.17 (when token_fd is 0),
probe_kern_uprobe_attach_type() will return 1 even on older kernels that do
not know about BPF_TRACE_UPROBE.

When bpf_object__load() -> bpf_object_load_prog() ->
libbpf_prepare_prog_load() then sets prog->expected_attach_type and
opts->expected_attach_type to BPF_TRACE_UPROBE on those older kernels:

tools/lib/bpf/libbpf.c:libbpf_prepare_prog_load() {
    ...
	if ((def & SEC_UPROBE) && kernel_supports(prog->obj, FEAT_UPROBE_ATTACH_TYPE)) {
		prog->expected_attach_type = BPF_TRACE_UPROBE;
		opts->expected_attach_type = BPF_TRACE_UPROBE;
	}
    ...
}

can this cause regressions for existing programs? For example:

1. In kernel/bpf/core.c, bpf_prog_map_compatible() requires matching
expected_attach_type values for BPF_MAP_TYPE_PROG_ARRAY:

kernel/bpf/core.c:bpf_prog_map_compatible() {
    ...
		if (ret &&
		    map->map_type == BPF_MAP_TYPE_PROG_ARRAY &&
		    map->owner->expected_attach_type != fp->expected_attach_type)
			ret = false;
    ...
}

Sharing a tail-call map between a SEC("uprobe") program (loaded with
expected_attach_type == BPF_TRACE_UPROBE) and a SEC("kprobe") program
(loaded with expected_attach_type == 0) will now fail.

2. Callers checking bpf_program__expected_attach_type() will observe
BPF_TRACE_UPROBE on kernels that neither enforce uprobe-only attach nor
disable the private stack for BPF_TRACE_UPROBE.

3. If FEAT_UPROBE_ATTACH_TYPE is cached without a token and later used when
loading a program with a BPF token on kernels 6.9+ prior to
BPF_TRACE_UPROBE, bpf_token_allow_prog_type() in kernel/bpf/token.c will
reject the load because attach_type >= __MAX_BPF_ATTACH_TYPE.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103093400.112178-1-jolsa@kernel.org?part=3

[PATCH bpf-next 4/4] selftests/bpf: Verify classic uprobe attach types

[Jiri Olsa]

Check that loaded uprobe and uretprobe programs retain
BPF_TRACE_UPROBE as their expected attach type.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 tools/testing/selftests/bpf/prog_tests/uprobe.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe.c b/tools/testing/selftests/bpf/prog_tests/uprobe.c
index 86404476c1da..7d372552f5ea 100644
--- a/tools/testing/selftests/bpf/prog_tests/uprobe.c
+++ b/tools/testing/selftests/bpf/prog_tests/uprobe.c
@@ -44,6 +44,10 @@ static void test_uprobe_attach(void)
 	skel = test_uprobe__open_and_load();
 	if (!ASSERT_OK_PTR(skel, "skel_open"))
 		return;
+	ASSERT_EQ(bpf_program__expected_attach_type(skel->progs.test1),
+		  BPF_TRACE_UPROBE, "uprobe_attach_type");
+	ASSERT_EQ(bpf_program__expected_attach_type(skel->progs.test3),
+		  BPF_TRACE_UPROBE, "uretprobe_attach_type");
 
 	urand_pipe = urand_spawn(&urand_pid);
 	if (!ASSERT_OK_PTR(urand_pipe, "urand_spawn"))
-- 
2.43.0

Re: [PATCH bpf-next 4/4] selftests/bpf: Verify classic uprobe attach types

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] bpf: classic uprobes with expected_attach_type 0 still use private stack
- [High] bpf: unchecked kprobe expected_attach_type breaks uprobe feature probe
--

commit 9ee5232694f8a364dae370cb864edf0a6d7ff502
Author: Jiri Olsa <jolsa@kernel.org>

selftests/bpf: Verify classic uprobe attach types

This commit adds assertions to the uprobe selftest to check that loaded
classic uprobe and uretprobe programs keep BPF_TRACE_UPROBE as their
expected attach type.

> diff --git a/tools/testing/selftests/bpf/prog_tests/uprobe.c b/tools/testing/selftests/bpf/prog_tests/uprobe.c
> index 86404476c1daf..7d372552f5eab 100644
> --- a/tools/testing/selftests/bpf/prog_tests/uprobe.c
> +++ b/tools/testing/selftests/bpf/prog_tests/uprobe.c
> @@ -44,6 +44,10 @@ static void test_uprobe_attach(void)
>  	skel = test_uprobe__open_and_load();
>  	if (!ASSERT_OK_PTR(skel, "skel_open"))
>  		return;
> +	ASSERT_EQ(bpf_program__expected_attach_type(skel->progs.test1),
> +		  BPF_TRACE_UPROBE, "uprobe_attach_type");
> +	ASSERT_EQ(bpf_program__expected_attach_type(skel->progs.test3),
> +		  BPF_TRACE_UPROBE, "uretprobe_attach_type");

[Severity: High]
Does the feature probe behind this expected_attach_type assignment actually
detect kernel support for BPF_TRACE_UPROBE?

In tools/lib/bpf/libbpf.c, libbpf_prepare_prog_load() sets
expected_attach_type when FEAT_UPROBE_ATTACH_TYPE is supported:

	/* set uprobe attach_type if supported */
	if ((def & SEC_UPROBE) && kernel_supports(prog->obj, FEAT_UPROBE_ATTACH_TYPE)) {
		prog->expected_attach_type = BPF_TRACE_UPROBE;
		opts->expected_attach_type = BPF_TRACE_UPROBE;
	}

In tools/lib/bpf/features.c, probe_kern_uprobe_attach_type() probes this by
calling bpf_prog_load() with BPF_PROG_TYPE_KPROBE and
opts.expected_attach_type = BPF_TRACE_UPROBE:

	fd = bpf_prog_load(BPF_PROG_TYPE_KPROBE, NULL, "GPL", insns,
			   ARRAY_SIZE(insns), &opts);
	return probe_fd(fd);

However, in kernel/bpf/syscall.c, bpf_prog_load_check_attach() does not have
a case for BPF_PROG_TYPE_KPROBE and falls into the default case:

	case BPF_PROG_TYPE_SYSCALL:
	case BPF_PROG_TYPE_EXT:
		if (expected_attach_type)
			return -EINVAL;
		fallthrough;
	default:
		return 0;

Because BPF_PROG_LOAD does not validate expected_attach_type for
BPF_PROG_TYPE_KPROBE, wouldn't probe_kern_uprobe_attach_type() always
succeed on older kernels too, causing libbpf to unconditionally set
BPF_TRACE_UPROBE while current kernels accept arbitrary invalid
expected_attach_type values for kprobe programs? Also, since
test_uprobe_attach() only checks the userspace getter
bpf_program__expected_attach_type(), should the test also verify that the
kernel rejects attaching a BPF_TRACE_UPROBE program to a non-uprobe perf
event?

[Severity: Critical]
In addition, can a classic uprobe program loaded with expected_attach_type
set to 0 still be assigned a per-CPU private stack and corrupt stack memory?

In kernel/bpf/verifier.c, bpf_enable_priv_stack() only disables the private
stack when expected_attach_type is explicitly set to one of the uprobe
attach types:

	case BPF_PROG_TYPE_KPROBE:
		/* Disable private stack for uprobe programs. */
		if (prog->expected_attach_type == BPF_TRACE_UPROBE ||
		    prog->expected_attach_type == BPF_TRACE_UPROBE_MULTI ||
		    prog->expected_attach_type == BPF_TRACE_UPROBE_SESSION)
			return NO_PRIV_STACK;
		fallthrough;

And in kernel/events/core.c, __perf_event_set_bpf_prog() still allows
attaching a BPF_PROG_TYPE_KPROBE program with expected_attach_type == 0 (and
jits_use_priv_stack == true) to a uprobe perf event:

	if (prog->expected_attach_type == BPF_TRACE_UPROBE && !is_uprobe)
		return -EINVAL;

	if (prog->type == BPF_PROG_TYPE_KPROBE && prog->sleepable && !is_uprobe)
		/* only uprobe programs are allowed to be sleepable */
		return -EINVAL;

If an existing userspace loader (or a sleepable BPF_PROG_TYPE_KPROBE program
loaded with expected_attach_type == 0) loads a program with stack depth >=
BPF_PRIV_STACK_MIN_SIZE and attaches it to a uprobe event, won't it still
receive PRIV_STACK_ADAPTIVE and overwrite the per-CPU private stack if
preempted on the same CPU?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261103093400.112178-1-jolsa@kernel.org?part=4

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

[Alexei Starovoitov]

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.

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;
+
 	if (is_tracepoint || is_syscall_tp) {
 		int off = trace_event_get_offsets(event->tp_event);

diff --git a/tools/testing/selftests/bpf/progs/verifier_large_stack.c b/tools/testing/selftests/bpf/progs/verifier_large_stack.c
index c2a3ddf..c366f00 100644
--- a/tools/testing/selftests/bpf/progs/verifier_large_stack.c
+++ b/tools/testing/selftests/bpf/progs/verifier_large_stack.c
@@ -226,7 +226,7 @@ static void priv_stack_frame_2048(void)
 "	::: __clobber_all);
 }

-SEC("kprobe")
+SEC("kprobe.multi")
 __description("private stack: two frames of 2048 bytes")
 __load_if_large_stack()
 __arch_x86_64
diff --git a/tools/testing/selftests/bpf/progs/verifier_private_stack.c b/tools/testing/selftests/bpf/progs/verifier_private_stack.c
index 3d9994a..4d74a40 100644
--- a/tools/testing/selftests/bpf/progs/verifier_private_stack.c
+++ b/tools/testing/selftests/bpf/progs/verifier_private_stack.c
@@ -22,7 +22,7 @@ struct {
 	__type(value, struct elem);
 } array SEC(".maps");

-SEC("kprobe")
+SEC("kprobe.multi")
 __description("Private stack, single prog")
 __success
 __arch_x86_64
@@ -70,6 +70,40 @@ __naked void no_private_stack_nested(void)
 "	::: __clobber_all);
 }

+SEC("uprobe")
+__description("No private stack, kprobe or uprobe")
+__success
+__arch_x86_64
+__jited("	subq	$0x100, %rsp")
+__arch_arm64
+__jited("	sub	sp, sp, #0x100")
+__naked void no_private_stack_uprobe(void)
+{
+	asm volatile ("			\
+	r1 = 42;			\
+	*(u64 *)(r10 - 256) = r1;	\
+	r0 = 0;				\
+	exit;				\
+"	::: __clobber_all);
+}
+
+SEC("uprobe.multi")
+__description("No private stack, uprobe.multi")
+__success
+__arch_x86_64
+__jited("	subq	$0x100, %rsp")
+__arch_arm64
+__jited("	sub	sp, sp, #0x100")
+__naked void no_private_stack_uprobe_multi(void)
+{
+	asm volatile ("			\
+	r1 = 42;			\
+	*(u64 *)(r10 - 256) = r1;	\
+	r0 = 0;				\
+	exit;				\
+"	::: __clobber_all);
+}
+
 __used
 __naked static void cumulative_stack_depth_subprog(void)
 {
@@ -83,7 +117,7 @@ __naked static void cumulative_stack_depth_subprog(void)
 	: __clobber_all);
 }

-SEC("kprobe")
+SEC("kprobe.multi")
 __description("Private stack, subtree > MAX_BPF_STACK")
 __success
 __log_level(4) __msg("stack depth max 512")

pw-bot: cr

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

[Jiri Olsa]

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) {