Linux kernel sockmap: missing kTLS guard in verdict data_ready leads to use-after-free

Impact

sk_psock_verdict_data_ready() lacked the kTLS receive-context check its strparser counterpart has. If a socket is put into a sockmap with a BPF_SK_SKB_VERDICT program before kernel TLS receive is configured, the psock callback drains the receive queue without advancing copied_seq; the TLS strparser then loads a message against an empty queue and is left with a frag_list pointing at an skb the psock already owns or freed, which tls_decrypt_sg() walks - a use-after-free in kernel context. This matters where a service mesh or L7 proxy uses sockmap/sk_skb redirection on the same sockets that terminate kTLS, a combination that appears in mesh data planes running alongside tenant workloads on GPU nodes. Triggering it needs the ability to load the BPF program and set up the socket, so this is not a path a plain unprivileged tenant pod has.

Who can reach it

Local, and privileged in practice: something must attach a BPF_SK_SKB_VERDICT program to a sockmap (CAP_BPF/CAP_NET_ADMIN) and then enable kTLS RX on the same socket. Remote traffic then drives the race, but an attacker cannot create the condition from outside.

What to do

Patched upstream - the verdict path now defers to saved_data_ready when a TLS RX context is present. Pick up the fix in your distribution's stable kernel (commits below) and reboot the node; there is no module to reload. On a GPU fleet, batch this with the next kernel maintenance window and drain nodes first. Interim mitigation: do not combine sockmap sk_skb verdict programs with kTLS receive on the same sockets.

References

Related entries

• Linux kernel (net/tls): A particular kTLS ring state builds a scatterlist whose chain link points directly at anotherCVE-2026-64046 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): When the kTLS transmit scatterlist ring wraps, the chain link that stitches the tail back toCVE-2026-64047 · Linux kernel (net/tls)Critical
• Linux kernel mlx5_core TX timeout devlink health reporter: The TX timeout recovery handler accesses the netdev pointerCVE-2026-64122 · Linux kernel mlx5_core TX timeout devlink health reporterCritical
• Linux kernel BPF devmap: cloning fragmented XDP frames for broadcast redirect reads out of boundsCVE-2026-64355 · Linux kernel BPF devmap (XDP broadcast redirect clone path)Critical
• Linux kernel krb5 crypto: use-after-free when an async AEAD backend is bound to the enctypeCVE-2026-64439 · Linux kernel krb5 crypto helpers (rfc3961_simplified / rfc8009_aes2 AEAD paths)Critical
• Linux kernel (drivers/nvme/target): A client connected to your NVMe-oF TCP target can drive a reference-count underflowCVE-2026-64534 · Linux kernel (drivers/nvme/target)Critical