Database/Kernel, userspace & hypervisor
Linux BPF offload: refcount increment on a dying netns causes use-after-free during info query
Impact
Querying info for an offloaded BPF map or program took the network namespace with get_net(dev_net(...)), which increments a refcount that may already have reached zero during netns teardown. rtnl_lock and bpf_devs_lock keep the netdev pointer valid but do nothing for the netns refcount, so the result is a refcount-on-zero use-after-free in the kernel. Be clear about who this reaches: only BPF objects offloaded to hardware take this path, which in practice means SmartNICs with BPF offload support. Nodes whose BPF programs run on the host CPU - the overwhelming majority of GPU fleets - never execute this code. Where hardware offload is in use, this is a local memory-corruption primitive on a node shared by tenants.
Who can reach it
Local, on a host with an offload-capable NIC, by a caller able to create and query offloaded BPF objects - CAP_BPF/CAP_NET_ADMIN, so root or a privileged pod - racing a network namespace being torn down. Not reachable from an unprivileged GPU pod, and not reachable at all without hardware BPF offload.
What to do
Take the stable kernel update and reboot each node. If your fleet does not use hardware BPF offload the code path is dead and this can wait for routine kernel maintenance. The record lists five stable commits and no fixed release version.
References
Related entries
- Linux kernel BPF verifier: ld_abs/ld_ind failure path left unverified inside subprogramsCVE-2026-53090 · Linux kernel BPF verifier (ld_abs/ld_ind in subprograms)High
- Linux kernel BPF verifier: mis-tracked rX += rX delta lets a program diverge from its verified boundsCVE-2026-53092 · Linux kernel BPF verifier (linked-register delta tracking in adjust_reg_min_max_vals())High
- Linux kernel amdkfd (KFD compute driver, /dev/kfd) (drm/amdkfd): An out-of-bounds access in the amdkfd (KFD computeCVE-2026-53143 · Linux kernel amdkfd (KFD compute driver, /dev/kfd) (drm/amdkfd)High
- Linux kernel list_lru: cgroup teardown race lets two CPUs unlink the same list item under different locksCVE-2026-53153 · Linux kernel mm/list_lru (memcg reparenting on cgroup teardown)High
- Linux kernel (net/xfrm): Policy deletion dropped the policy lock before pruning the inexact-policy bin, and aCVE-2026-53239 · Linux kernel (net/xfrm)High
- Linux kernel IPv6: heap overwrite into skb_shared_info via UDPv6 MSG_MORE with MSG_SPLICE_PAGESCVE-2026-53362 · Linux kernel IPv6 (__ip6_append_data paged allocation path)High
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.