On Fri, Feb 20, 2026 at 10:57:56AM +0000, [email protected] wrote: > > 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.
