> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 68600972a..010785246 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
[ ... ]
> @@ -1863,6 +1864,10 @@ union bpf_attr {
> };
> __u64 expected_revision;
> } cgroup;
> + struct {
> + __aligned_u64 btf_ids; /* addresses to
> attach */
> + __u32 btf_ids_cnt; /* addresses
> count */
> + } tracing_multi;
The comments say "addresses to attach" and "addresses count", but the field is
named btf_ids and contains BTF type IDs, not addresses. Should these comments
say "BTF IDs to attach" and "BTF IDs count" instead?
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index f7baeb827..82e625aa0 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
[ ... ]
> +static void bpf_tracing_multi_link_show_fdinfo(const struct bpf_link *link,
> + struct seq_file *seq)
> +{
> + struct bpf_tracing_multi_link *tr_link =
> + container_of(link, struct bpf_tracing_multi_link, link);
> +
> + seq_printf(seq, "attach_type:\t%d\n", tr_link->attach_type);
> +}
> +
> +static int bpf_tracing_multi_link_fill_link_info(const struct bpf_link *link,
> + struct bpf_link_info *info)
> +{
> + struct bpf_tracing_multi_link *tr_link =
> + container_of(link, struct bpf_tracing_multi_link, link);
> +
> + info->tracing.attach_type = tr_link->attach_type;
> + return 0;
> +}
Both functions above use tr_link->attach_type, but looking at
bpf_tracing_multi_attach() below, this field is never initialized:
> +int bpf_tracing_multi_attach(struct bpf_prog *prog, const union bpf_attr
> *attr)
> +{
[ ... ]
> + link = kzalloc(struct_size(link, nodes, cnt), GFP_KERNEL);
> + if (!link) {
> + err = -ENOMEM;
> + goto error;
> + }
> +
> + link->nodes_cnt = cnt;
> +
> + bpf_link_init(&link->link, BPF_LINK_TYPE_TRACING_MULTI,
> + &bpf_tracing_multi_link_lops, prog,
> prog->expected_attach_type);
bpf_link_init() sets link->link.attach_type (inside the embedded struct
bpf_link),
but struct bpf_tracing_multi_link has a separate attach_type field that remains
zero-initialized from kzalloc.
The show_fdinfo and fill_link_info callbacks read tr_link->attach_type which
will always be 0 (BPF_CGROUP_INET_INGRESS) instead of the actual attach type
(BPF_TRACE_FENTRY_MULTI or BPF_TRACE_FEXIT_MULTI).
Looking at the existing bpf_tracing_link_show_fdinfo() and
bpf_tracing_link_fill_link_info() in kernel/bpf/syscall.c, they use
link->attach_type (the inner struct's field). Should tr_link->attach_type
either be removed and link->attach_type used instead, or should it be
explicitly initialized to prog->expected_attach_type?
---
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/21625440628
AI-authorship-score: low
AI-authorship-explanation: Code style and structure are consistent with
established kernel BPF patterns, with typical kernel author conventions in
commit message and implementation.
issues-found: 2
issue-severity-score: medium
issue-severity-explanation: Uninitialized attach_type field causes wrong data
to be returned to userspace via fdinfo and bpf_link_info, affecting
observability but not causing crashes.
