On Wed, Mar 04, 2026 at 11:02:31PM +0000, [email protected] wrote: > > 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 > > [ ... ] > > > +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?
should call free_fentry_multi_data, will fix, thnx jirka
