Linux kernel sockmap: cork use-after-free when two threads send on the same socket

Impact

tcp_bpf_sendmsg() decided whether its message was the local temporary or the shared psock cork by comparing against psock->cork after sk_stream_wait_memory() had dropped and reacquired the socket lock. A second thread completing the cork in that window makes the stale pointer look local, and it is freed twice - KASAN reports a slab use-after-free. What makes this one worth attention is who can reach it: the sockmap has to be installed by a privileged component (Cilium sockops/sk_msg acceleration, or a sidecar-less mesh), but the trigger is ordinary multithreaded sending by the workload whose sockets are in that map. On a shared GPU node that is a tenant-reachable slab UAF, not a root-only one.

Who can reach it

Any local process whose sockets have been added to a sockmap - a pod on a node running sockmap-based socket acceleration - sending from two threads while an sk_msg allocation fails. The sender needs no capabilities; a privileged component must have installed the sockmap.

What to do

Update to a stable kernel with the fix and reboot each affected node. Where that cannot happen quickly, turning off sockmap-based socket acceleration in the dataplane (the sockops/sk_msg path) removes the code path entirely at a throughput cost. Reboots mean draining GPU jobs first; of the kernel items in this batch, this is the one with the widest reachable audience, so schedule it ahead of the root-only ones.

References