Linux kernel (net/tls): If the skb clone that pins the input buffer for an async decrypt cannot be allocated, kTLS

Impact

If the skb clone that pins the input buffer for an async decrypt cannot be allocated, kTLS proceeds with the decrypt anyway. The result is a use-after-free on the skb and, worse, the crypto engine writing plaintext into the caller's userspace buffer after recv() has already returned - so decrypted bytes land in whatever that address space has since reused the page.

Who can reach it

Remote and unauthenticated relative to the TLS data path: a peer sending records to any kTLS RX socket drives the async decrypt, and the failing clone allocation is inducible with memory pressure a co-tenant can generate. No device node or privilege needed; applies to tenant traffic and to node storage/control-plane connections using kTLS.

What to do

Boot a kernel carrying the linked stable commits. Interim: disable async crypto offload for kTLS (avoid cryptd-backed AEAD drivers) or terminate TLS in userspace on exposed nodes.

References