Executive brief
The Linux kernel's TLS (Transport Layer Security) networking stack contains a locking vulnerability that allows an attacker to hang legitimate network transmission tasks indefinitely. By keeping the receive window at zero, an adversary can force threads waiting to send data to block permanently on a mutex lock, preventing any further communication and causing a denial of service condition on systems using encrypted network connections.
Technical details
The vulnerability exists in the TLS send path (net/tls/tls_sw.c) where threads acquiring the tx_lock mutex may block indefinitely if an adversarial receiver maintains a zero receive window (RWIN=0) for extended periods. The root cause is the use of blocking mutex_lock() calls in tls_sw_sendmsg() and tls_sw_sendpage(), combined with a blocking wait in the tx_work_handler() work queue. An attacker on the network can keep RWIN at zero to prevent forward progress, causing the thread holding tx_lock to sleep for hours without releasing the lock, starving other threads. The fix replaces blocking mutex_lock() with mutex_lock_interruptible() for user-triggered sends and converts tx_work_handler() to use mutex_trylock() with delayed rescheduling, allowing tasks to be interrupted and work to be retried rather than hung indefinitely. No remote code execution or data exposure occurs; the impact is strictly denial of service through resource exhaustion.
Affected products
- Linux Linux kernel multiple versions prior to fix in commit f3221361dc85d4de22586ce8441ec2c67b454f5d
Timeline
- 2023-02-28: disclosed: Patch published by Jakub Kicinski
- 2023-03-11: patched: Merged to stable kernel branches