Re: [PATCH bpf-next 10/17] bpf: Add support for tracing_multi link session

On Fri, Feb 20, 2026 at 10:57:56AM +0000, bot+bpf-ci@kernel.org wrote:

quoted

diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 5892dca20b7e..1cd6c1457bd3 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c

@@ -3611,6 +3611,7 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
 		if (prog->expected_attach_type != BPF_TRACE_FENTRY &&
 		    prog->expected_attach_type != BPF_TRACE_FEXIT &&
 		    prog->expected_attach_type != BPF_TRACE_FSESSION &&
+		    prog->expected_attach_type != BPF_TRACE_FSESSION_MULTI &&
 		    prog->expected_attach_type != BPF_TRACE_FENTRY_MULTI &&
 		    prog->expected_attach_type != BPF_TRACE_FEXIT_MULTI &&
 		    prog->expected_attach_type != BPF_MODIFY_RETURN) {

BPF_TRACE_FSESSION_MULTI is now accepted here, which means
a program with this type can enter bpf_tracing_prog_attach()
via BPF_RAW_TRACEPOINT_OPEN:

bpf_raw_tracepoint_open()
  bpf_raw_tp_link_attach()       /* name == NULL */
    bpf_tracing_prog_attach()    /* BPF_TRACE_FSESSION_MULTI */

Further down in bpf_tracing_prog_attach(), the fexit node
initialization only checks for BPF_TRACE_FSESSION:

kernel/bpf/syscall.c:bpf_tracing_prog_attach() {
    ...
    if (prog->expected_attach_type == BPF_TRACE_FSESSION) {
        link->fexit.link = &link->link.link;
        link->fexit.cookie = bpf_cookie;
    }
    ...
}

So for BPF_TRACE_FSESSION_MULTI, link->fexit.link stays NULL
(from kzalloc). When __bpf_trampoline_link_prog() later calls
fsession_exit(), it returns &link->fexit with a NULL link
field. This node gets added to the trampoline FEXIT list, and
bpf_trampoline_get_progs() then dereferences it:

kernel/bpf/trampoline.c:bpf_trampoline_get_progs() {
    ...
    hlist_for_each_entry(node, &tr->progs_hlist[kind], tramp_hlist) {
        *ip_arg |= node->link->prog->call_get_func_ip;
                   ^^^^^^^^^^
    ...
}

Would it make sense to either add BPF_TRACE_FSESSION_MULTI to
the fexit initialization, or reject this type in
bpf_tracing_prog_attach() since it should only be used through
bpf_tracing_multi_attach()?

yes, I think we need to reject or MULTI types in bpf_raw_tracepoint_open,
it's allowed to attach only through new multi_link attach api,

good catch, thnx

jirka

---
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/22220470181

AI-authorship-score: low
AI-authorship-explanation: Code follows established kernel BPF patterns for adding new attach types, written by a well-known BPF maintainer with terse, practical commit message style.
issues-found: 1
issue-severity-score: high
issue-severity-explanation: NULL pointer dereference reachable from BPF_RAW_TRACEPOINT_OPEN syscall when BPF_TRACE_FSESSION_MULTI enters bpf_tracing_prog_attach without fexit initialization, leading to kernel crash.