> 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?
> +
> + 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
