When querying info for an offloaded BPF map or program,
bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns()
obtain the network namespace with get_net(dev_net(offmap->netdev)).
However, the associated netdev's netns may be racing with teardown
during netns destruction. If the netns refcount has already reached 0,
get_net() performs a refcount_t increment on 0, triggering:

  refcount_t: addition on 0; use-after-free.

Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains
valid, they cannot prevent the netns refcount from reaching zero.

Fix this by using maybe_get_net() instead of get_net(). maybe_get_net()
uses refcount_inc_not_zero() and returns NULL if the refcount is already
zero, which causes ns_get_path_cb() to fail and the caller to return
-ENOENT -- the correct behavior when the netns is being destroyed.

Fixes: 675fc275a3a2d ("bpf: offload: report device information for offloaded programs")
Fixes: 52775b33bb507 ("bpf: offload: report device information about offloaded maps")
Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Closes: https://lore.kernel.org/bpf/f0aa3678-79c9-47ae-9e8c-02a3d1df160a@hust.edu.cn/
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
---
v1 -> v2: fix the commit message and simplify to ternary.
v1: https://lore.kernel.org/bpf/20260408104732.259683-1-jiayuan.chen@linux.dev/
---
 kernel/bpf/offload.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c
index 0ad97d643bf49..0d6f5569588c3 100644
--- a/kernel/bpf/offload.c
+++ b/kernel/bpf/offload.c
@@ -435,9 +435,8 @@ static struct ns_common *bpf_prog_offload_info_fill_ns(void *private_data)
 
 	if (aux->offload) {
 		args->info->ifindex = aux->offload->netdev->ifindex;
-		net = dev_net(aux->offload->netdev);
-		get_net(net);
-		ns = &net->ns;
+		net = maybe_get_net(dev_net(aux->offload->netdev));
+		ns = net ? &net->ns : NULL;
 	} else {
 		args->info->ifindex = 0;
 		ns = NULL;
@@ -647,9 +646,8 @@ static struct ns_common *bpf_map_offload_info_fill_ns(void *private_data)
 
 	if (args->offmap->netdev) {
 		args->info->ifindex = args->offmap->netdev->ifindex;
-		net = dev_net(args->offmap->netdev);
-		get_net(net);
-		ns = &net->ns;
+		net = maybe_get_net(dev_net(args->offmap->netdev));
+		ns = net ? &net->ns : NULL;
 	} else {
 		args->info->ifindex = 0;
 		ns = NULL;
-- 
2.43.0

On 4/9/26 4:37 AM, Jiayuan Chen wrote:
> When querying info for an offloaded BPF map or program,
> bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns()
> obtain the network namespace with get_net(dev_net(offmap->netdev)).
> However, the associated netdev's netns may be racing with teardown
> during netns destruction. If the netns refcount has already reached 0,
> get_net() performs a refcount_t increment on 0, triggering:
> 
>    refcount_t: addition on 0; use-after-free.
> 
> Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains
> valid, they cannot prevent the netns refcount from reaching zero.
> 
> Fix this by using maybe_get_net() instead of get_net(). maybe_get_net()
> uses refcount_inc_not_zero() and returns NULL if the refcount is already
> zero, which causes ns_get_path_cb() to fail and the caller to return
> -ENOENT -- the correct behavior when the netns is being destroyed.
> 
> Fixes: 675fc275a3a2d ("bpf: offload: report device information for offloaded programs")
> Fixes: 52775b33bb507 ("bpf: offload: report device information about offloaded maps")
> Reported-by: Yinhao Hu <dddddd@hust.edu.cn>
> Reported-by: Kaiyan Mei <M202472210@hust.edu.cn>
> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
> Closes: https://lore.kernel.org/bpf/f0aa3678-79c9-47ae-9e8c-02a3d1df160a@hust.edu.cn/
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
> v1 -> v2: fix the commit message and simplify to ternary.
> v1: https://lore.kernel.org/bpf/20260408104732.259683-1-jiayuan.chen@linux.dev/
Acked-by: Daniel Borkmann <daniel@iogearbox.net>

(should go into bpf-next)