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