GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux BPF offload: refcount increment on a dying netns causes use-after-free during info query

CVSS 7.8CVE-2026-53089Kernel, userspace & hypervisorcurated

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

All Kernel, userspace & hypervisor entries

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.