> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
[ ... ]
> +int bpf_tracing_multi_attach(struct bpf_prog *prog, const union bpf_attr
> *attr)
> +{
> + struct bpf_tracing_multi_link *link = NULL;
> + struct bpf_link_primer link_primer;
> + u32 cnt, *ids = NULL;
> + u32 __user *uids;
> + int err;
> +
> + uids = u64_to_user_ptr(attr->link_create.tracing_multi.ids);
> + cnt = attr->link_create.tracing_multi.cnt;
> +
> + if (!cnt || !uids)
> + return -EINVAL;
Should attr->link_create.flags be validated here as well?
Both bpf_kprobe_multi_link_attach() and bpf_uprobe_multi_link_attach()
reject non-zero flags:
kernel/trace/bpf_trace.c:bpf_kprobe_multi_link_attach() {
...
if (attr->link_create.flags)
return -EINVAL;
...
}
Without this check, userspace passing flags != 0 will be silently
accepted, which would prevent using the flags field for future
extensions since old kernels could not be distinguished from new
ones.
> + if (cnt > MAX_TRACING_MULTI_CNT)
> + return -E2BIG;
[ ... ]
> +#else
> +
> +int bpf_tracing_multi_attach(struct bpf_prog *prog, const union bpf_attr
> *attr)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +#endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS) &&
> CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS */
Minor: there is a stray ')' after CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
in this comment.
---
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
