> 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()?
---
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.
