Linux kernel (net/tls): The async crypto callback signalled completion before scheduling the transmit work, so the

Impact

The async crypto callback signalled completion before scheduling the transmit work, so the submitting thread could exit and free the socket context while the callback was still queueing work against it - a use-after-free on the kTLS transmit path.

Who can reach it

Remote peers drive the record flow; the race closes on a socket close or syscall return, which an attacker can encourage by resetting connections against a kTLS sender. Any kTLS TX socket on the node, no privilege or device node needed. Requires an async-capable AEAD driver.

What to do

Boot a kernel carrying the linked stable commits, along with the rest of the tls async series. Interim: disable async crypto offload for kTLS.

References

Related entries

• Linux kernel (net/tls): When a decrypt goes to the crypto backlog and a sibling decrypt fails, the error path releasesCVE-2024-26800 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): The synchronous decrypt path shared refcounting and completion state with the async path, so aCVE-2024-58240 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): The strparser kept a stale reference to an skb that TCP had already coalesced away, and theCVE-2025-38471 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): A zero-length record already sitting on the rx_list breaks the invariant that zero-copy decryptCVE-2025-39682 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): When the socket buffer is too small to hold a whole record, kTLS parses early and re-parses asCVE-2025-39946 · Linux kernel (net/tls)Critical
• Linux kernel (net/tls): If the skb clone that pins the input buffer for an async decrypt cannot be allocated, kTLSCVE-2025-40176 · Linux kernel (net/tls)Critical