Re: [PATCHv2 bpf-next 08/23] bpf: Add bpf_trampoline_multi_attach/detach functions
From: bot+bpf-ci@kernel.org
Date: 2026-03-04 23:02:31
Also in:
bpf
quoted hunk ↗ jump to hunk
diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c index e2f4a15886b0..c42bf16b6807 100644 --- a/kernel/bpf/trampoline.c +++ b/kernel/bpf/trampoline.c
[ ... ]
quoted hunk ↗ jump to hunk
+int bpf_trampoline_multi_detach(struct bpf_prog *prog, struct bpf_tracing_multi_link *link) +{ + struct bpf_tracing_multi_node *mnode; + struct fentry_multi_data data = {}; + int i, cnt = link->nodes_cnt; + + data.unreg = alloc_ftrace_hash(FTRACE_HASH_DEFAULT_BITS); + data.modify = alloc_ftrace_hash(FTRACE_HASH_DEFAULT_BITS); + + if (!data.unreg || !data.modify) { + free_ftrace_hash(data.unreg); + return -ENOMEM; + }
If data.unreg allocation fails but data.modify succeeds, only free_ftrace_hash(data.unreg) is called (which is a no-op on NULL). Wouldn't data.modify be leaked in that case? The attach function handles this correctly by using free_fentry_multi_data() which frees all three hashes. Could the detach error path also free data.modify?
+ + trampoline_lock_all();
[ ... ] --- 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/22692622038