Linux kernel (net/tls): A receiver that holds its TCP window at zero keeps the kTLS sender blocked inside tx_lock

Impact

A receiver that holds its TCP window at zero keeps the kTLS sender blocked inside tx_lock indefinitely, so the thread holding the lock never releases it and the TLS transmit work item wedges. Hung-task reports follow, and the blocked work item ties up the shared workqueue that other sockets on the node depend on.

Who can reach it

Remote and entirely under the peer's control: any client or server the node speaks kTLS to can advertise a zero receive window and hold it. This applies to tenant-facing endpoints and to any node service that opens kTLS connections to addresses a tenant influences. No local access needed.

What to do

Boot a kernel carrying the linked stable commits (which use interruptible sleep and reschedule the work rather than blocking). Interim: set send timeouts on kTLS sockets and cap per-connection lifetime for peer-facing endpoints.

References

Related entries

• Linux kernel (net/tls): If a page allocation fails while the TLS strparser is copying a partial record, the receiveCVE-2025-38018 · Linux kernel (net/tls)High
• Linux kernel (net/tls): The queue that pins encrypted input buffers while the AEAD engine still references them wasCVE-2026-23414 · Linux kernel (net/tls)High
• Linux kernel (net/tls): When kTLS RX offload fails at tls_dev_add, the rollback frees the software context but neverCVE-2026-52974 · Linux kernel (net/tls)High
• Linux kernel (net/tls): A remote peer sends a zero-length TLS 1.3 application_data record - which the RFC explicitlyCVE-2026-72330 · Linux kernel (net/tls)High
• Linux kernel (net/tls): A BPF sockmap psock could be attached to a socket that already had the kTLS ULP installed. TheCVE-2022-49732 · Linux kernel (net/tls)Medium
• Linux kernel (net/tls): Sendfile() on a kTLS socket whose plaintext and ciphertext buffers are both empty drives theCVE-2023-52767 · Linux kernel (net/tls)Medium