> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 49368ee161b1..9bf7e8754c7b 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c

[ ... ]

> @@ -12510,6 +12592,197 @@ bool btf_type_is_traceable_func(const struct btf 
> *btf, const struct btf_type *t
>       return true;
>  }
>
> +static int collect_func_ids_by_glob(const struct bpf_program *prog, const 
> char *pattern, __u32 **ids)
> +{
> +     struct bpf_object *obj = prog->obj;
> +     const struct module_btf *mod;
> +     struct btf *btf = NULL;
> +     const char *sep;
> +     int err;
> +
> +     err = bpf_object__load_vmlinux_btf(obj, true);
> +     if (err)
> +             return err;
> +
> +     /* In case we have module specified, we will find its btf and use that. 
> */
> +     sep = strchr(pattern, ':');
> +     if (sep) {
> +             mod = find_attach_module(obj, pattern);
> +             if (!mod) {
> +                     err = -EINVAL;
> +                     goto cleanup;
> +             }
> +             btf = mod->btf;
> +             pattern = sep + 1;
> +     } else {
> +             /* Program is loaded for kernel module. */
> +             if (prog->attach_btf_obj_fd)
> +                     return -EINVAL;
> +             btf = obj->btf_vmlinux;
> +     }
> +
> +     err = collect_btf_func_ids_by_glob(btf, pattern, ids);
> +
> +cleanup:
> +     bpf_object_cleanup_btf(obj);
> +     return err;
> +}

Does this function leak the vmlinux BTF when prog->attach_btf_obj_fd is
set? The early return bypasses the cleanup label that calls
bpf_object_cleanup_btf(obj). Every other error path goes through
cleanup, which suggests the BTF loaded by bpf_object__load_vmlinux_btf()
needs to be cleaned up before returning.

The design pattern here is that bpf_object__load_vmlinux_btf(obj, true)
is called specifically at attach-time (after the object has already been
post-load-cleaned), so obj->btf_vmlinux is freshly loaded. Skipping the
cleanup leaves that freshly-loaded btf_vmlinux attached to the bpf_object
until bpf_object__close().

Should this be 'err = -EINVAL; goto cleanup;' to match the other error
paths?

[ ... ]


---
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/24598000047

Reply via email to