[PATCH bpf-next 0/2] bpf: Reject BTF ids with the same address in tracing_multi link

[PATCH bpf-next 0/2] bpf: Reject BTF ids with the same address in tracing_multi link

[Alexei Starovoitov]

From: Alexei Starovoitov <ast@kernel.org>

tracing_multi link accepts different BTF ids that resolve to the same
address. The attach succeeds, the detach fails in ftrace and the kernel
crashes in freed trampoline images.
'test_progs -t tracing_multi' hits it when the kernel is built with
CONFIG_DEBUG_INFO_BTF_INLINE. Without it the ids of aliased functions do
the same.

Patch 1 - the fix.
Patch 2 - selftest.

Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Alexei Starovoitov (2):
  bpf: Reject BTF ids with the same address in tracing_multi link
  selftests/bpf: Test tracing_multi link with BTF ids of the same
    address

 include/linux/ftrace.h                        |  1 +
 kernel/bpf/trampoline.c                       |  8 ++
 kernel/trace/trace.h                          |  3 -
 .../selftests/bpf/prog_tests/tracing_multi.c  | 99 +++++++++++++++++++
 4 files changed, 108 insertions(+), 3 deletions(-)

-- 
2.55.0

[PATCH bpf-next 1/2] bpf: Reject BTF ids with the same address in tracing_multi link

[Alexei Starovoitov]

From: Alexei Starovoitov <ast@kernel.org>

check_dup_ids() rejects equal BTF ids, but different ids can resolve to
the same address. Aliases:

  ffffffff8161b6b0 t __do_sys_munlockall
  ffffffff8161b6b0 T __ia32_sys_munlockall
  ffffffff8161b6b0 T __x64_sys_munlockall

or several BTF_KIND_FUNC with the same name that vmlinux BTF has when
CONFIG_DEBUG_INFO_BTF_INLINE is set.

Each id gets its own trampoline and register_fentry_multi() adds them to
data->reg with the same ip. update_ftrace_direct_add() checks that new
entries are not in direct_functions, but doesn't compare them with each
other, so the attach succeeds. At detach update_ftrace_direct_del() sees
that 'direct' of one of the entries doesn't match and returns -EINVAL:

  WARNING: kernel/bpf/trampoline.c:1845 at bpf_trampoline_multi_detach+0x24c/0x280
  Call Trace:
   bpf_link_free+0x51/0x110
   bpf_link_release+0x18/0x20
   __fput+0x103/0x2d0
   __x64_sys_close+0x3d/0x80

The images are freed anyway, while ftrace still calls them:

  Oops: int3: 0000 [#1] SMP NOPTI
  RIP: 0010:0xffffffffc042b201
  Call Trace:
   ? __audit_syscall_exit+0x9/0x100
   ? do_syscall_64+0x5ab/0x5e0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  Kernel panic - not syncing: Fatal exception in interrupt

Return -EINVAL from register_fentry_multi() when ip is already in
data->reg. When such ids are attached via different links the second
attach already fails with -EINVAL in update_ftrace_direct_add().

Move the declaration of ftrace_lookup_ip() to include/linux/ftrace.h.

The lookup adds 60 msec to the attach of 64480 functions in
tracing_multi_bench_attach: 1.34 -> 1.40 sec.

Fixes: aef4dfa790b2 ("bpf: Add bpf_trampoline_multi_attach/detach functions")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
 include/linux/ftrace.h  | 1 +
 kernel/bpf/trampoline.c | 8 ++++++++
 kernel/trace/trace.h    | 3 ---
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index bd76a16a63af..b041d9142d2b 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -416,6 +416,7 @@ void free_ftrace_hash(struct ftrace_hash *hash);
 struct ftrace_func_entry *add_ftrace_hash_entry_direct(struct ftrace_hash *hash,
 						       unsigned long ip, unsigned long direct);
 void add_ftrace_hash_entry(struct ftrace_hash *hash, struct ftrace_func_entry *entry);
+struct ftrace_func_entry *ftrace_lookup_ip(struct ftrace_hash *hash, unsigned long ip);
 void ftrace_hash_remove(struct ftrace_hash *hash);
 
 /* The hash used to know what functions callbacks trace */
diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
index fc94d6062109..24edb59238f3 100644
--- a/kernel/bpf/trampoline.c
+++ b/kernel/bpf/trampoline.c
@@ -1638,6 +1638,14 @@ static int register_fentry_multi(struct bpf_trampoline *tr, struct bpf_tramp_ima
 	unsigned long ip = ftrace_location(tr->ip);
 	struct bpf_tracing_multi_data *data = ptr;
 
+	/*
+	 * Different BTF ids get different trampolines, but they can still
+	 * resolve to the same address (aliases, functions of the same name).
+	 * There's only one call site to attach to.
+	 */
+	if (ftrace_lookup_ip(data->reg, ip))
+		return -EINVAL;
+
 	if (bpf_trampoline_use_jmp(tr->flags))
 		addr = ftrace_jmp_set(addr);
 
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 3749485a7d85..9044f03fe2d9 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1006,9 +1006,6 @@ struct ftrace_hash {
 	struct rcu_head		rcu;
 };
 
-struct ftrace_func_entry *
-ftrace_lookup_ip(struct ftrace_hash *hash, unsigned long ip);
-
 static __always_inline bool ftrace_hash_empty(struct ftrace_hash *hash)
 {
 	return !hash || !(hash->count || (hash->flags & FTRACE_HASH_FL_MOD));
-- 
2.55.0

[PATCH bpf-next 2/2] selftests/bpf: Test tracing_multi link with BTF ids of the same address

[Alexei Starovoitov]

From: Alexei Starovoitov <ast@kernel.org>

The stub of a syscall without arguments is an alias of its __do_sys_
function. Find such pair where both have BTF ids. Which ones do depends
on the compiler, so don't hard code the names. Check that each id can be
attached and that the attach of both in one link fails with -EINVAL.

With CONFIG_DEBUG_INFO_BTF_INLINE vmlinux BTF has 26 names with more
than one BTF_KIND_FUNC:

  [117318] FUNC 'hash' type_id=76715 linkage=static
  [117319] FUNC 'hash' type_id=76722 linkage=static
  [117320] FUNC 'hash' type_id=76789 linkage=static

while there is one 'hash' in kallsyms. tracing_multi_bench_attach skips
the names that are not unique in kallsyms only and passes all three ids
to the kernel. Take the first id of the name.

Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
 .../selftests/bpf/prog_tests/tracing_multi.c  | 99 +++++++++++++++++++
 1 file changed, 99 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/tracing_multi.c b/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
index 0aa9532a05cf..cc727011f3a2 100644
--- a/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
+++ b/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
@@ -662,6 +662,97 @@ static void test_attach_api_fails(void)
 	free(ids2);
 }
 
+/*
+ * Find two BTF ids that resolve to the same address. The stub of a syscall
+ * without arguments is an alias of its __do_sys_ function.
+ */
+static bool get_same_addr_ids(__u32 *ids)
+{
+	const char *prefix = "__x64_sys_";
+	__u32 nr, type_id;
+	bool found = false;
+	struct btf *btf;
+	char alias[128];
+
+	btf = btf__load_vmlinux_btf();
+	if (!ASSERT_OK_PTR(btf, "btf__load_vmlinux_btf"))
+		return false;
+
+	nr = btf__type_cnt(btf);
+	for (type_id = 1; type_id < nr && !found; type_id++) {
+		const struct btf_type *type = btf__type_by_id(btf, type_id);
+		const char *str;
+		long addr;
+		__s32 id;
+
+		if (!btf_is_func(type))
+			continue;
+
+		str = btf__name_by_offset(btf, type->name_off);
+		if (!str || strncmp(str, prefix, strlen(prefix)))
+			continue;
+
+		snprintf(alias, sizeof(alias), "__do_sys_%s", str + strlen(prefix));
+		id = btf__find_by_name_kind(btf, alias, BTF_KIND_FUNC);
+		if (id <= 0)
+			continue;
+
+		addr = ksym_get_addr(str);
+		if (!addr || addr != ksym_get_addr(alias))
+			continue;
+
+		ids[0] = type_id;
+		ids[1] = id;
+		found = true;
+	}
+
+	btf__free(btf);
+	return found;
+}
+
+static void test_attach_same_addr(void)
+{
+	LIBBPF_OPTS(bpf_tracing_multi_opts, opts);
+	struct tracing_multi_fail *skel;
+	struct bpf_link *link;
+	__u32 ids[2];
+	int i;
+
+	if (!ASSERT_OK(load_kallsyms(), "load_kallsyms"))
+		return;
+
+	if (!get_same_addr_ids(ids)) {
+		test__skip();
+		return;
+	}
+
+	skel = tracing_multi_fail__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "tracing_multi_fail__open_and_load"))
+		return;
+
+	/* Each id attaches fine on its own.. */
+	for (i = 0; i < 2; i++) {
+		opts.ids = &ids[i];
+		opts.cnt = 1;
+
+		link = bpf_program__attach_tracing_multi(skel->progs.test_fentry, NULL, &opts);
+		if (!ASSERT_OK_PTR(link, "attach_single"))
+			goto cleanup;
+		bpf_link__destroy(link);
+	}
+
+	/* ..but there's only one call site, so not both of them. */
+	opts.ids = ids;
+	opts.cnt = 2;
+
+	link = bpf_program__attach_tracing_multi(skel->progs.test_fentry, NULL, &opts);
+	if (!ASSERT_EQ(libbpf_get_error(link), -EINVAL, "attach_same_addr"))
+		bpf_link__destroy(link);
+
+cleanup:
+	tracing_multi_fail__destroy(skel);
+}
+
 void serial_test_tracing_multi_bench_attach(void)
 {
 	LIBBPF_OPTS(bpf_tracing_multi_opts, opts);
@@ -748,6 +839,12 @@ void serial_test_tracing_multi_bench_attach(void)
 		if (!btf_type_is_traceable_func(btf, type))
 			continue;
 
+		/*
+		 * BTF can have more functions of the same name and they all
+		 * resolve to the same address, take just the first one.
+		 */
+		tdelete(&str, &root, compare);
+
 		err = libbpf_ensure_mem((void **) &ids, &cap, sizeof(*ids), cnt + 1);
 		if (err)
 			goto cleanup;
@@ -1023,6 +1120,8 @@ void test_tracing_multi_test(void)
 		test_session();
 	if (test__start_subtest("attach_api_fails"))
 		test_attach_api_fails();
+	if (test__start_subtest("attach_same_addr"))
+		test_attach_same_addr();
 	RUN_TESTS(tracing_multi_verifier);
 	if (test__start_subtest("fentry_after_multi"))
 		test_fentry_after_multi();
-- 
2.55.0

Re: [PATCH bpf-next 2/2] selftests/bpf: Test tracing_multi link with BTF ids of the same address

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

> selftests/bpf: Test tracing_multi link with BTF ids of the same address

TL;DR: Test nit only: the attach_same_addr subtest skips without printing a
reason, so a SKIP is hard to interpret. A printf() before test__skip() could
help, though the review says a bare skip may be acceptable.

> diff --git a/tools/testing/selftests/bpf/prog_tests/tracing_multi.c b/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
> --- a/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
> +++ b/tools/testing/selftests/bpf/prog_tests/tracing_multi.c

[ ... ]

> @@ -662,6 +662,97 @@ static void test_attach_api_fails(void)
>  	free(ids2);
>  }
>
[ ... ]
> +static void test_attach_same_addr(void)
> +{
> +	LIBBPF_OPTS(bpf_tracing_multi_opts, opts);
> +	struct tracing_multi_fail *skel;
> +	struct bpf_link *link;
> +	__u32 ids[2];
> +	int i;
> +
> +	if (!ASSERT_OK(load_kallsyms(), "load_kallsyms"))
> +		return;
> +
> +	if (!get_same_addr_ids(ids)) {
> +		test__skip();
> +		return;
> +	}

A subsystem pattern flags this skip as potentially concerning.  The
selftests guide says to report a test that skips silently with no
message.

When get_same_addr_ids() finds no __x64_sys_X / __do_sys_X pair that has
BTF FUNC entries and shares an address, test__skip() is called without
printing a reason.  The commit message says which pairs exist depends on
the compiler, so this skip can happen on some toolchains.

Someone looking at an "attach_same_addr:SKIP" line cannot tell whether
vmlinux BTF lacks the aliases or kallsyms did not resolve them.  Would a
one-line printf() before test__skip() make the skip self-explanatory?  For
example:

	printf("no __x64_sys_/__do_sys_ alias pair with BTF ids\n");

On the other side, test__skip() takes no arguments and the framework does
print a SKIP line for the subtest.  A bare test__skip() is a common idiom
in prog_tests/, and this file already uses it twice for the non-x86_64
skip, so this may be acceptable as is.

[ ... ]

---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/38159103930

Re: [PATCH bpf-next 2/2] selftests/bpf: Test tracing_multi link with BTF ids of the same address

[Alexei Starovoitov]

On Sun Oct 11, 2026 at 6:15 PM UTC, bot+bpf-ci wrote:
>> selftests/bpf: Test tracing_multi link with BTF ids of the same address
>
> TL;DR: Test nit only: the attach_same_addr subtest skips without printing a
> reason, so a SKIP is hard to interpret. A printf() before test__skip() could
> help, though the review says a bare skip may be acceptable.

...

> A subsystem pattern flags this skip as potentially concerning.  The
> selftests guide says to report a test that skips silently with no
> message.

bpf-ci... seriously?

humans and bots MUST not report nits.

Re: [PATCH bpf-next 0/2] bpf: Reject BTF ids with the same address in tracing_multi link

[Leon Hwang]

cc Jiri

On 12/10/26 00:48, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
> 
> tracing_multi link accepts different BTF ids that resolve to the same
> address. The attach succeeds, the detach fails in ftrace and the kernel
> crashes in freed trampoline images.
> 'test_progs -t tracing_multi' hits it when the kernel is built with
> CONFIG_DEBUG_INFO_BTF_INLINE. Without it the ids of aliased functions do
> the same.

Without CONFIG_DEBUG_INFO_BTF_INLINE, the patch 2 selftest also
reproduces the warning.

The fix lgtm.

Acked-by: Leon Hwang <leon.hwang@linux.dev>

Re: [PATCH bpf-next 0/2] bpf: Reject BTF ids with the same address in tracing_multi link

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Kumar Kartikeya Dwivedi <memxor@gmail.com>:

On Sun, 11 Oct 2026 16:48:34 +0000 you wrote:
> From: Alexei Starovoitov <ast@kernel.org>
> 
> tracing_multi link accepts different BTF ids that resolve to the same
> address. The attach succeeds, the detach fails in ftrace and the kernel
> crashes in freed trampoline images.
> 'test_progs -t tracing_multi' hits it when the kernel is built with
> CONFIG_DEBUG_INFO_BTF_INLINE. Without it the ids of aliased functions do
> the same.
> 
> [...]

Here is the summary with links:
  - [bpf-next,1/2] bpf: Reject BTF ids with the same address in tracing_multi link
    https://git.kernel.org/bpf/bpf-next/c/7211c18d7ee5
  - [bpf-next,2/2] selftests/bpf: Test tracing_multi link with BTF ids of the same address
    https://git.kernel.org/bpf/bpf-next/c/60e84b9127f6

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH bpf-next 0/2] bpf: Reject BTF ids with the same address in tracing_multi link

[Jiri Olsa]

On Sun, Oct 11, 2026 at 04:48:34PM +0000, Alexei Starovoitov wrote:
> From: Alexei Starovoitov <ast@kernel.org>
> 
> tracing_multi link accepts different BTF ids that resolve to the same
> address. The attach succeeds, the detach fails in ftrace and the kernel
> crashes in freed trampoline images.
> 'test_progs -t tracing_multi' hits it when the kernel is built with
> CONFIG_DEBUG_INFO_BTF_INLINE. Without it the ids of aliased functions do
> the same.
> 
> Patch 1 - the fix.
> Patch 2 - selftest.
> 
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>

nice, fwiw:

Acked-by: Jiri Olsa <jolsa@kernel.org>

thanks,
jirka


> 
> Alexei Starovoitov (2):
>   bpf: Reject BTF ids with the same address in tracing_multi link
>   selftests/bpf: Test tracing_multi link with BTF ids of the same
>     address
> 
>  include/linux/ftrace.h                        |  1 +
>  kernel/bpf/trampoline.c                       |  8 ++
>  kernel/trace/trace.h                          |  3 -
>  .../selftests/bpf/prog_tests/tracing_multi.c  | 99 +++++++++++++++++++
>  4 files changed, 108 insertions(+), 3 deletions(-)
> 
> -- 
> 2.55.0
> 
> 

Re: [PATCH bpf-next 0/2] bpf: Reject BTF ids with the same address in tracing_multi link

[Leon Hwang]

On 12/10/26 13:30, patchwork-bot+netdevbpf@kernel.org wrote:
> Hello:
> 
> This series was applied to bpf/bpf-next.git (master)
> by Kumar Kartikeya Dwivedi <memxor@gmail.com>:
> 
> On Sun, 11 Oct 2026 16:48:34 +0000 you wrote:
>> From: Alexei Starovoitov <ast@kernel.org>
>>
>> tracing_multi link accepts different BTF ids that resolve to the same
>> address. The attach succeeds, the detach fails in ftrace and the kernel
>> crashes in freed trampoline images.
>> 'test_progs -t tracing_multi' hits it when the kernel is built with
>> CONFIG_DEBUG_INFO_BTF_INLINE. Without it the ids of aliased functions do
>> the same.
>>
>> [...]
> 
> Here is the summary with links:
>   - [bpf-next,1/2] bpf: Reject BTF ids with the same address in tracing_multi link
>     https://git.kernel.org/bpf/bpf-next/c/7211c18d7ee5
>   - [bpf-next,2/2] selftests/bpf: Test tracing_multi link with BTF ids of the same address
>     https://git.kernel.org/bpf/bpf-next/c/60e84b9127f6
> 
> You are awesome, thank you!


Oops, the applied commits did not collect my Acked-by tags.

Pls collect the Acked-by tags from Jiri and me.

Thanks,
Leon

Re: [PATCH bpf-next 0/2] bpf: Reject BTF ids with the same address in tracing_multi link

[Kumar Kartikeya Dwivedi]

On Mon Oct 12, 2026 at 10:26 AM CEST, Leon Hwang wrote:
> On 12/10/26 13:30, patchwork-bot+netdevbpf@kernel.org wrote:
>> Hello:
>>
>> This series was applied to bpf/bpf-next.git (master)
>> by Kumar Kartikeya Dwivedi <memxor@gmail.com>:
>>
>> On Sun, 11 Oct 2026 16:48:34 +0000 you wrote:
>>> From: Alexei Starovoitov <ast@kernel.org>
>>>
>>> tracing_multi link accepts different BTF ids that resolve to the same
>>> address. The attach succeeds, the detach fails in ftrace and the kernel
>>> crashes in freed trampoline images.
>>> 'test_progs -t tracing_multi' hits it when the kernel is built with
>>> CONFIG_DEBUG_INFO_BTF_INLINE. Without it the ids of aliased functions do
>>> the same.
>>>
>>> [...]
>>
>> Here is the summary with links:
>>   - [bpf-next,1/2] bpf: Reject BTF ids with the same address in tracing_multi link
>>     https://git.kernel.org/bpf/bpf-next/c/7211c18d7ee5
>>   - [bpf-next,2/2] selftests/bpf: Test tracing_multi link with BTF ids of the same address
>>     https://git.kernel.org/bpf/bpf-next/c/60e84b9127f6
>>
>> You are awesome, thank you!
>
>
> Oops, the applied commits did not collect my Acked-by tags.
>
> Pls collect the Acked-by tags from Jiri and me.
>

Fixed and force pushed.

> Thanks,
> Leon