Skip to content

bpf: Allow uprobe_multi binary specified by file descriptor#12432

Open
kernel-patches-daemon-bpf[bot] wants to merge 6 commits into
bpf-next_basefrom
series/1109332=>bpf-next
Open

bpf: Allow uprobe_multi binary specified by file descriptor#12432
kernel-patches-daemon-bpf[bot] wants to merge 6 commits into
bpf-next_basefrom
series/1109332=>bpf-next

Conversation

@kernel-patches-daemon-bpf

Copy link
Copy Markdown

Pull request for series with
subject: bpf: Allow uprobe_multi binary specified by file descriptor
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1109332

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 140fa23
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1109332
version: 1

@kernel-patches-review-bot

Copy link
Copy Markdown
commit c97b5014c8951882497999017b83efe25ea211b5
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Add support to specify uprobe_multi target via file descriptor

This patch lets a uprobe_multi link identify its target binary by an
already opened file descriptor.  It adds the BPF_F_UPROBE_MULTI_PATH_FD
flag and a path_fd field to attr.link_create.uprobe_multi, resolving the
target from path_fd when the flag is set and keeping the existing string
path behavior otherwise.

> 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")

> 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

In-Reply-To-Subject: bpf: Add support to specify uprobe_multi target via file descriptor
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27284577665

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 2e8ad1f
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1109332
version: 1

@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Resolve the uprobe_multi user path with user_path_at() instead of copying
the string with strndup_user() and passing it to kern_path(). This removes
the temporary allocation and keeps the lookup logic in one helper.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
@kernel-patches-daemon-bpf

Copy link
Copy Markdown
Author

Upstream branch: 30dee2c
series: https://patchwork.kernel.org/project/netdevbpf/list/?series=1109332
version: 1

olsajiri added 5 commits June 10, 2026 16:25
Allow uprobe_multi link to identify the target binary by an already
opened file descriptor.

Adding new BPF_F_UPROBE_MULTI_PATH_FD flag and the path_fd field for
the attr.link_create.uprobe_multi struct.

When the flag is set, we resolve the target from path_fd, without the
flag, we keep the existing string path behavior.

I don't see a use case for supporting O_PATH file descriptors, because
we need to read the binary first to get probes offsets, so I'm using
the CLASS(fd, f), which fails for O_PATH fds.

Assisted-by: Codex:GPT-5.4
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Adding the path_fd field to struct bpf_link_create_opts and passing it
through kernel attr interface.

Assisted-by: Codex:GPT-5.4
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Add a uprobe_multi link API selftest that opens /proc/self/exe and passes
the resulting descriptor through opts.uprobe_multi.path_fd with
BPF_F_UPROBE_MULTI_PATH_FD set.

Assisted-by: Codex:GPT-5.4
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Adding tests to attach_api_fails suite to make sure we fail
wrong setup for path_fd usage.

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
We verify info.uprobe_multi.flags against wrong kprobe-multi flag
(BPF_F_KPROBE_MULTI_RETURN). It's the same value as the correct
flag (BPF_F_UPROBE_MULTI_RETURN), so there's not functional change.

Fixes: 147c693 ("selftests/bpf: Add link_info test for uprobe_multi link")
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
@kernel-patches-daemon-bpf kernel-patches-daemon-bpf Bot force-pushed the series/1109332=>bpf-next branch from 339ef5e to 3c35ba2 Compare June 10, 2026 23:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant