Re: [PATCH bpf v6 1/4] bpf: Fix potential UAF in bpf_netns_link_update_prog

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Preexisting Use-After-Free in generic bpf_link information retrieval and mprog attachment due to lockless access to link->prog.
--

--- Patch [1]: [PATCH bpf v6 1/4] bpf: Fix potential UAF in bpf_netns_link_update_prog ---
commit d5c566078955c1f4dfc1d9f1e23e9f6213c3dcfb
Author: Pu Lehui <pulehui@huawei.com>

bpf: Fix potential UAF in bpf_netns_link_update_prog

This commit fixes a potential use-after-free issue in
bpf_netns_link_update_prog() by moving the old_prog and prog->type checks
inside the netns_bpf_mutex critical section.

> diff --git a/kernel/bpf/net_namespace.c b/kernel/bpf/net_namespace.c
> index 25f30f9edaefd..9fc62db1441c6 100644
> --- a/kernel/bpf/net_namespace.c
> +++ b/kernel/bpf/net_namespace.c
> @@ -171,13 +171,17 @@ static int bpf_netns_link_update_prog(struct bpf_link *link,
>  	struct net *net;
>  	int idx, ret;
>  
> -	if (old_prog && old_prog != link->prog)
> -		return -EPERM;
> -	if (new_prog->type != link->prog->type)
> -		return -EINVAL;
> -
>  	mutex_lock(&netns_bpf_mutex);
>  
> +	if (old_prog && old_prog != link->prog) {
> +		ret = -EPERM;
> +		goto out_unlock;
> +	}
> +	if (new_prog->type != link->prog->type) {
> +		ret = -EINVAL;
> +		goto out_unlock;
> +	}
> +

[Severity: High]
This isn't a bug introduced by this patch, but while this change fixes the
concurrent update race in bpf_netns_link_update_prog(), could the subsequent
xchg() of link->prog cause a use-after-free regression in other functions
that read it locklessly?

If a user-space application concurrently calls bpf_obj_get_info_by_fd() or
reads fdinfo, the retrieval functions read link->prog locklessly without
holding rcu_read_lock(). If the reader thread is preempted immediately after
reading the pointer, and a concurrent link update replaces and frees the old
program, will the reader dereference freed memory?

This can happen in bpf_link_get_info_by_fd():

    if (link->prog)
        info.prog_id = link->prog->aux->id;

It also appears in bpf_link_show_fdinfo():

    const struct bpf_prog *prog = link->prog;
    ...
    bin2hex(prog_tag, prog->tag, sizeof(prog->tag));

And in bpf_mprog_link():

    if (type && link->prog->type != type) {

Do these lockless accesses need rcu_read_lock() protection to safely read
the program fields when updates can happen concurrently?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722072326.1545677-1-pulehui@huaweicloud.com?part=1