GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel eBPF: syncookie helpers read sk_protocol on mini-sockets without a fullsock check

CVSS 7.3CVE-2026-80738Kernel, userspace & hypervisorcurated

Impact

Both helpers accept a socket pointer typed ARG_PTR_TO_BTF_ID_SOCK_COMMON and then dereference sk->sk_protocol, a field that only exists on full sockets. Handing them a request or time-wait mini-socket reads outside the allocated object. NVD scores it local with confidentiality and integrity impact, which fits an out-of-bounds read of kernel memory reachable from an attacker-shaped BPF program. On a GPU node the exposure is the host network stack and whatever privileged components load BPF there, typically the CNI and eBPF-based observability agents, rather than an ordinary tenant pod. The fix short-circuits on sk_state != TCP_LISTEN, since mini-sockets are never in TCP_LISTEN.

Who can reach it

Local, and it requires the privilege to load eBPF programs that call these helpers: CAP_BPF plus CAP_NET_ADMIN, or root. A tenant confined to an unprivileged GPU pod cannot reach it; a container granted BPF capability for networking or tracing can, as can any local user with root on the node.

What to do

Take the stable-tree fix (linked commits) via a distribution kernel update and boot into it. There is no runtime switch, so this is a rolling drain and reboot across the fleet, which on GPU nodes means evicting long-running training jobs. Until the reboot, the mitigation is to keep CAP_BPF and CAP_NET_ADMIN off tenant workloads and limit BPF loading to the platform agents you ship.

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.