Linux kernel BPF sockmap: unhashed UDP sockets leak socket refcounts, exhausting host memory

UnscoredCVE-2026-68386Kernel, userspace & hypervisorcurated

Impact

sockmap accepted unbound UDP sockets. Because UDP sets SOCK_RCU_FREE when bound, a socket looked up by a BPF program while unbound and then bound afterwards never gets its refcount decremented by bpf_sk_release(), so struct sock allocations accumulate and are never freed. On a node running a service mesh, CNI or observability agents that use sockmap, this is an unbounded kernel memory leak that ends in OOM pressure on the host rather than a control-flow compromise. A GPU node that hits memory pressure has to be drained and rebooted, which is expensive when long-running training jobs are resident. Exploiting it requires the ability to load or influence BPF programs, which is not a normal tenant capability.

Who can reach it

Local, and privileged in practice: needs CAP_BPF/CAP_NET_ADMIN to attach a program that populates a sockmap, or a workload already permitted to do so. Not reachable from an unprivileged pod under a default policy.

What to do

Apply the stable kernel fix from the linked git.kernel.org commits or your distribution's backport; this is a host kernel change, so plan a drain and reboot per node. As an interim control, confirm which components on your GPU hosts use sockmap and keep BPF-loading capabilities off tenant workloads. No fixed release version is given in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-68386 https://git.kernel.org/stable/c/17b7ef6b86112a4e61cee1e9009a4b318e3225c5 https://git.kernel.org/stable/c/250474c69bc3fc48a5fc21d7c349f279caad947a

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.