[PATCH bpf v2] bpf: Fix potential UAF in bpf_netns_link_update_prog

[PATCH bpf v2] bpf: Fix potential UAF in bpf_netns_link_update_prog

[Pu Lehui]

From: Pu Lehui <pulehui@huawei.com>

In bpf_netns_link_update_prog, the checks for old_prog and prog type
are currently performed locklessly before acquiring netns_bpf_mutex.
This creates a race condition that can lead to a UAF issue.

If two threads concurrently execute BPF_LINK_UPDATE on the same netns
link, the following execution path can trigger a UAF:

CPU0                                          CPU1
bpf_netns_link_update_prog
  if (old_prog && old_prog != link->prog)
    return -EPERM;
                                              bpf_netns_link_update_prog
                                                if (old_prog && old_prog != link->prog)
                                                ...
                                                old_prog = xchg(&link->prog, new_prog);
                                                bpf_prog_put(old_prog);
  if (new_prog->type != link->prog->type) <-- trigger UAF

Fix this by moving the old_prog and prog->type checks inside the
netns_bpf_mutex critical section. Meanwhile, use guard() to simplify
lock management and avoid all the goto jumping.

Fixes: 7f045a49fee0 ("bpf: Add link-based BPF program attachment to network namespace")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Reviewed-by: Amery Hung <ameryhung@gmail.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
v2:
- Use guard() to avoid all the goto jumping. (Andrii)
- Add Reviewed-by tags by Amery and Emil.
- Separate from patchset [0]. (Andrii)

Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [0]

v1: https://lore.kernel.org/bpf/20260720134547.1289964-1-pulehui@huaweicloud.com

 kernel/bpf/net_namespace.c | 17 ++++++-----------
 1 file changed, 6 insertions(+), 11 deletions(-)

diff --git a/kernel/bpf/net_namespace.c b/kernel/bpf/net_namespace.c
index 25f30f9edaef..81006a242618 100644
--- a/kernel/bpf/net_namespace.c
+++ b/kernel/bpf/net_namespace.c
@@ -171,33 +171,28 @@ static int bpf_netns_link_update_prog(struct bpf_link *link,
 	struct net *net;
 	int idx, ret;
 
+	guard(mutex)(&netns_bpf_mutex);
+
 	if (old_prog && old_prog != link->prog)
 		return -EPERM;
 	if (new_prog->type != link->prog->type)
 		return -EINVAL;
 
-	mutex_lock(&netns_bpf_mutex);
-
 	net = net_link->net;
-	if (!net || !check_net(net)) {
+	if (!net || !check_net(net))
 		/* Link auto-detached or netns dying */
-		ret = -ENOLINK;
-		goto out_unlock;
-	}
+		return -ENOLINK;
 
 	run_array = rcu_dereference_protected(net->bpf.run_array[type],
 					      lockdep_is_held(&netns_bpf_mutex));
 	idx = link_index(net, type, net_link);
 	ret = bpf_prog_array_update_at(run_array, idx, new_prog);
 	if (ret)
-		goto out_unlock;
+		return ret;
 
 	old_prog = xchg(&link->prog, new_prog);
 	bpf_prog_put(old_prog);
-
-out_unlock:
-	mutex_unlock(&netns_bpf_mutex);
-	return ret;
+	return 0;
 }
 
 static int bpf_netns_link_fill_info(const struct bpf_link *link,
-- 
2.34.1

Re: [PATCH bpf v2] bpf: Fix potential UAF in bpf_netns_link_update_prog

[sashiko-bot]

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

Pre-existing issues:
- [Critical] Lockless, unprotected access to `link->prog` fields allows Use-After-Free and TOCTOU bugs when a link's program is updated concurrently.
--

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

bpf: Fix potential UAF in bpf_netns_link_update_prog

This commit fixes a potential use-after-free in bpf_netns_link_update_prog
by moving the checks for old_prog and new_prog->type inside the
netns_bpf_mutex critical section. It also uses guard(mutex) to simplify
lock management.

Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [0]

> diff --git a/kernel/bpf/net_namespace.c b/kernel/bpf/net_namespace.c
> index 25f30f9edaefd..81006a242618d 100644
> --- a/kernel/bpf/net_namespace.c
> +++ b/kernel/bpf/net_namespace.c
> @@ -171,33 +171,28 @@ static int bpf_netns_link_update_prog(struct bpf_link *link,
>  	struct net *net;
>  	int idx, ret;
>  
> +	guard(mutex)(&netns_bpf_mutex);
> +
>  	if (old_prog && old_prog != link->prog)
>  		return -EPERM;
>  	if (new_prog->type != link->prog->type)
>  		return -EINVAL;
>  
[ ... ]
>  	old_prog = xchg(&link->prog, new_prog);
>  	bpf_prog_put(old_prog);

[Severity: Critical]
This is a pre-existing issue, but can this concurrent update race with
lockless readers of link->prog in other parts of the code?

For example, in bpf_link_get_info_by_fd():

kernel/bpf/syscall.c:bpf_link_get_info_by_fd() {
    ...
    if (link->prog)
        info.prog_id = link->prog->aux->id;
    ...
}

Or in bpf_link_show_fdinfo():

kernel/bpf/syscall.c:bpf_link_show_fdinfo() {
    ...
    const struct bpf_prog *prog = link->prog;
    ...
    if (prog) {
        bin2hex(prog_tag, prog->tag, sizeof(prog->tag));
    ...
}

Could these lockless reads lead to a use-after-free if a thread executing
bpf_netns_link_update_prog() swaps link->prog and drops the reference to
old_prog, and the RCU grace period elapses before the reader accesses the
freed program's fields?

Similarly, in bpf_mprog_link() in kernel/bpf/mprog.c:

kernel/bpf/mprog.c:bpf_mprog_link() {
    ...
    if (type && link->prog->type != type) {
        bpf_link_put(link);
        return -EINVAL;
    }
    
    tuple->link = link;
    tuple->prog = link->prog;
    ...
}

Could this lead to a time-of-check to time-of-use error or a dangling
tuple->prog pointer if a link update occurs concurrently?

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

Re: [PATCH bpf v2] bpf: Fix potential UAF in bpf_netns_link_update_prog

[Pu Lehui]

On 2026/7/28 10:39, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [Critical] Lockless, unprotected access to `link->prog` fields allows Use-After-Free and TOCTOU bugs when a link's program is updated concurrently.
> --
> 
> --- Patch [1]: [PATCH bpf v2] bpf: Fix potential UAF in bpf_netns_link_update_prog ---
> commit afa2c5a0786c29e2f3227e6c9b10cbfcd8407bc9
> Author: Pu Lehui <pulehui@huawei.com>
> 
> bpf: Fix potential UAF in bpf_netns_link_update_prog
> 
> This commit fixes a potential use-after-free in bpf_netns_link_update_prog
> by moving the checks for old_prog and new_prog->type inside the
> netns_bpf_mutex critical section. It also uses guard(mutex) to simplify
> lock management.
> 
> Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [0]
> 
>> diff --git a/kernel/bpf/net_namespace.c b/kernel/bpf/net_namespace.c
>> index 25f30f9edaefd..81006a242618d 100644
>> --- a/kernel/bpf/net_namespace.c
>> +++ b/kernel/bpf/net_namespace.c
>> @@ -171,33 +171,28 @@ static int bpf_netns_link_update_prog(struct bpf_link *link,
>>   	struct net *net;
>>   	int idx, ret;
>>   
>> +	guard(mutex)(&netns_bpf_mutex);
>> +
>>   	if (old_prog && old_prog != link->prog)
>>   		return -EPERM;
>>   	if (new_prog->type != link->prog->type)
>>   		return -EINVAL;
>>   
> [ ... ]
>>   	old_prog = xchg(&link->prog, new_prog);
>>   	bpf_prog_put(old_prog);
> 
> [Severity: Critical]
> This is a pre-existing issue, but can this concurrent update race with
> lockless readers of link->prog in other parts of the code?

The follow patch has been covered this issue.

https://lore.kernel.org/bpf/20260728025457.2814876-1-pulehui@huaweicloud.com

> 
> For example, in bpf_link_get_info_by_fd():
> 
> kernel/bpf/syscall.c:bpf_link_get_info_by_fd() {
>      ...
>      if (link->prog)
>          info.prog_id = link->prog->aux->id;
>      ...
> }
> 
> Or in bpf_link_show_fdinfo():
> 
> kernel/bpf/syscall.c:bpf_link_show_fdinfo() {
>      ...
>      const struct bpf_prog *prog = link->prog;
>      ...
>      if (prog) {
>          bin2hex(prog_tag, prog->tag, sizeof(prog->tag));
>      ...
> }
> 
> Could these lockless reads lead to a use-after-free if a thread executing
> bpf_netns_link_update_prog() swaps link->prog and drops the reference to
> old_prog, and the RCU grace period elapses before the reader accesses the
> freed program's fields?
> 
> Similarly, in bpf_mprog_link() in kernel/bpf/mprog.c:
> 
> kernel/bpf/mprog.c:bpf_mprog_link() {
>      ...
>      if (type && link->prog->type != type) {
>          bpf_link_put(link);
>          return -EINVAL;
>      }
>      
>      tuple->link = link;
>      tuple->prog = link->prog;
>      ...
> }
> 
> Could this lead to a time-of-check to time-of-use error or a dangling
> tuple->prog pointer if a link update occurs concurrently?
>