Linux kernel (net/tls): A BPF sockmap psock could be attached to a socket that already had the kTLS ULP installed. The

Impact

A BPF sockmap psock could be attached to a socket that already had the kTLS ULP installed. The psock teardown path then unwinds the ULP and calls tcp_update_ulp() with the ULP's own protocol ops, so the ULP loops its own callbacks - a protocol-ops confusion between two layers that both think they own sk->sk_prot, ending in runaway recursion on the node.

Who can reach it

Needs the ability to add a socket to a BPF sockmap (CAP_BPF/CAP_NET_ADMIN - in practice the node's CNI, a service-mesh sidecar, or a tenant granted BPF), against a socket that already has kTLS enabled. Both halves are normal in an encrypted service mesh, so the collision arises without an attacker if kTLS and sockmap are used together; a tenant with BPF access can force it deliberately.

What to do

Boot a kernel carrying the linked stable commits. Interim: do not grant CAP_BPF to tenant containers, and do not run sockmap/sk_msg policy over kTLS sockets on the same node.

References