Re: [PATCHv2 bpf-next 2/6] bpf: Add support to specify uprobe_multi target via file descriptor

[Jiri Olsa <olsajiri@gmail.com>]

On Wed, Jun 10, 2026 at 03:51:39PM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> > index d4188a992bd8..cef9bd6316a5 100644
> > --- a/kernel/bpf/syscall.c
> > +++ b/kernel/bpf/syscall.c
> > @@ -3475,7 +3475,7 @@ static void bpf_link_show_fdinfo(struct seq_file *m, struct file *filp)
> >  			seq_printf(m, "link_type:\t%s\n", link->flags == BPF_F_KPROBE_MULTI_RETURN ?
> >  				   "kretprobe_multi" : "kprobe_multi");
> >  		else if (link->type == BPF_LINK_TYPE_UPROBE_MULTI)
> > -			seq_printf(m, "link_type:\t%s\n", link->flags == BPF_F_UPROBE_MULTI_RETURN ?
> > +			seq_printf(m, "link_type:\t%s\n", link->flags & BPF_F_UPROBE_MULTI_RETURN ?
> >  				   "uretprobe_multi" : "uprobe_multi");
> 
> This change in bpf_link_show_fdinfo() switches the uprobe_multi check from
> an equality test to a bitwise test.  Once a second flag bit exists (the
> BPF_F_UPROBE_MULTI_PATH_FD flag added by this same patch), a uretprobe_multi
> link created with both flags set would be misreported as "uprobe_multi"
> because the equality test no longer matches.
> 
> The equality comparison was introduced in:
> 
>   803f0700a3bb ("bpf: Show precise link_type for {uprobe,kprobe}_multi fdinfo")
> 
> Should this change include:
> 
>   Fixes: 803f0700a3bb ("bpf: Show precise link_type for {uprobe,kprobe}_multi fdinfo")

answered this one in previous version

jirka

> 
> > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> > index 970ce7bbf99e..f5d68f6d90f3 100644
> > --- a/kernel/trace/bpf_trace.c
> > +++ b/kernel/trace/bpf_trace.c
> > @@ -3214,6 +3215,38 @@ static u64 bpf_uprobe_multi_cookie(struct bpf_run_ctx *ctx)
> >  	return run_ctx->uprobe->cookie;
> >  }
> >
> > +static int bpf_uprobe_multi_get_path(const union bpf_attr *attr, struct path *path)
> > +{
> > +	void __user *upath = u64_to_user_ptr(attr->link_create.uprobe_multi.path);
> > +	u32 path_fd = attr->link_create.uprobe_multi.path_fd;
> > +	u32 flags = attr->link_create.uprobe_multi.flags;
> > +
> > +	if (flags & BPF_F_UPROBE_MULTI_PATH_FD) {
> 
> [ ... ]
> 
> > +	}
> > +
> > +	/*
> > +	 * When BPF_F_UPROBE_MULTI_PATH_FD is not set, the path is resolved
> > +	 * relative to the cwd (AT_FDCWD) or absolute using the upath string.
> > +	 */
> > +	if (!upath || path_fd)
> > +		return -EINVAL;
> 
> This isn't a bug, but the non-FD branch (taken when
> BPF_F_UPROBE_MULTI_PATH_FD is not set) reads path_fd in the check
> 'if (!upath || path_fd)'.
> 
> path_fd is only meaningful when BPF_F_UPROBE_MULTI_PATH_FD is set.  A caller
> that supplies a valid string path but leaves path_fd as non-zero garbage (in
> a struct large enough to include path_fd) would get a spurious -EINVAL here.
> 
> The garbage value is never dereferenced or used for arithmetic, so this looks
> more like defensive input validation than a dangerous use, and old-style
> callers passing the pre-path_fd struct size get path_fd zeroed and pass
> cleanly.
> 
> Is rejecting a non-zero path_fd in the string-path mode intended, or should
> path_fd be ignored when the flag is absent?
> 
> > +
> > +	return user_path_at(AT_FDCWD, upath, LOOKUP_FOLLOW, path);
> > +}
> 
> 
> ---
> 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/27284577665