Re: [PATCHv2 bpf-next 1/6] bpf: Use user_path_at for path resolution in uprobe_multi

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] Missing `access_ok()` checks before calling `__get_user()` on user-controlled arrays, leading to arbitrary kernel memory read.
--

commit e18574361f20d4f27005e4d927610e3ce16986dd
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Use user_path_at for path resolution in uprobe_multi

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.

> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index 90432f0fc2a8e..970ce7bbf99e1 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c

[ ... ]

> @@ -3261,14 +3260,7 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>  	uref_ctr_offsets = u64_to_user_ptr(attr->link_create.uprobe_multi.ref_ctr_offsets);
>  	ucookies = u64_to_user_ptr(attr->link_create.uprobe_multi.cookies);
>  
> -	name = strndup_user(upath, PATH_MAX);
> -	if (IS_ERR(name)) {
> -		err = PTR_ERR(name);
> -		return err;
> -	}
> -
> -	err = kern_path(name, LOOKUP_FOLLOW, &path);
> -	kfree(name);
> +	err = user_path_at(AT_FDCWD, upath, LOOKUP_FOLLOW, &path);
>  	if (err)
>  		return err;
>  

[Severity: Critical]
This isn't a bug introduced by this patch, but while looking at
bpf_uprobe_multi_link_attach(), I noticed the user-provided arrays
uoffsets, uref_ctr_offsets, and ucookies are accessed shortly after this
path resolution:

kernel/trace/bpf_trace.c:bpf_uprobe_multi_link_attach() {
    ...
    if (__get_user(uprobes[i].offset, uoffsets + i)) {
    ...
    if (uref_ctr_offsets && __get_user(uprobes[i].ref_ctr_offset, uref_ctr_offsets + i)) {
    ...
    if (ucookies && __get_user(uprobes[i].cookie, ucookies + i)) {
    ...
}

Are these arrays validated with access_ok() before __get_user() is called?

Because __get_user() bypasses the access_ok() address-space bounds check
on most architectures, could an attacker supply kernel addresses for these
arrays, causing the kernel to read arbitrary memory and store it into the
uprobes structures?

If an attacker retrieves these contents by querying the link info via
bpf_obj_get_info_by_fd() (which calls bpf_uprobe_multi_link_fill_link_info()
and copies the memory back to user space), could this act as an arbitrary
kernel memory read primitive to bypass kernel lockdown and KASLR?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610143627.804790-2-jolsa@kernel.org?part=1