Linux kernel (net/tls): Tls_init published the new sk_prot before the TLS context was fully initialized, so a

Impact

Tls_init published the new sk_prot before the TLS context was fully initialized, so a concurrent setsockopt/getsockopt on the same socket can see ctx->sk_proto as NULL and dereference it. An unprivileged tenant gets a kernel NULL dereference out of the kTLS crypto-info setsockopt path.

Who can reach it

Local and unprivileged: one thread enables the TLS ULP while another calls setsockopt/getsockopt(SOL_TLS) on the same socket. No device node, no capability. The store-store reordering the race needs is real on weakly-ordered CPUs (arm64 - which is what Grace/GH200-class head nodes are), and much harder to hit on x86.

What to do

Boot a kernel carrying the linked stable commits. Interim: none at the tenant boundary; on arm64 nodes consider blacklisting the tls module where kTLS is not required.

References