GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel sk_clone: early bailout frees the parent socket's BPF storage, causing a use-after-free

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

Impact

sock_copy() shallow-copies ->sk_bpf_storage into the new socket. If sk_clone() bails out before bpf_sk_storage_clone() runs - for example when sk_filter_charge() fails - the clone is freed while still pointing at the parent socket's BPF local storage, and __sk_destruct() destroys storage the parent is still using. That is a use-after-free on a live socket reachable from the normal accept path. This matters on GPU nodes because BPF socket-local storage is what CNI dataplanes such as Cilium and most eBPF observability agents use, so the affected code is in the hot path on an ordinary Kubernetes worker rather than in an exotic subsystem. Impact is kernel memory corruption, so a host crash that drops every GPU pod on the node, or privilege escalation on a shared node.

Who can reach it

Local. A workload that can create sockets on a host whose sockets carry BPF local storage, and that can drive sk_clone() into its early error path (for example by exhausting the socket filter memory charge). No authentication beyond running code on the node, so any tenant pod qualifies on a node with an eBPF CNI.

What to do

Take the stable kernel fix - sk_clone() now clears newsk->sk_bpf_storage immediately after sock_copy() - and reboot each node. No mitigation short of removing the eBPF programs that attach socket-local storage, which on an eBPF CNI means losing the dataplane. Drain and reboot on the normal kernel-update rotation unless the fleet is multi-tenant, which raises the priority.

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.