CVE-2026-72330 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
net/tls: Consume empty data records in tls_sw_read_sock()
A peer may send a zero-length TLS application_data record; TLS 1.3 explicitly permits these as a traffic-analysis countermeasure (RFC 8446, Section 5.1). After decryption such a record has full_len == 0. tls_sw_read_sock() hands it to the read_actor, which has no payload to consume and returns zero. The loop treats a zero return as backpressure (used <= 0), requeues the skb at the head of rx_list, and stops. rx_list is serviced head-first on the next call, so the empty record is dequeued, fails the same way, and is requeued again; every later record on the connection is blocked behind it.
tls_sw_recvmsg() does not stall on this: a zero-length data record copies nothing and falls through to consume_skb(). Mirror that in the read_sock() path by recognizing an empty data record before the actor runs, consuming it, and continuing.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described represents a critical denial-of-service condition affecting the Linux kernel's TLS implementation, specifically within the software-based TLS subsystem. This flaw manifests in the net/tls component where the tls_sw_read_sock() function fails to properly handle zero-length TLS application_data records that are legitimately permitted under TLS 1.3 specifications. The issue stems from the kernel's handling of empty data records that serve as traffic-analysis countermeasures as explicitly outlined in RFC 8446, section 5.1, where such records are intentionally sent to obscure communication patterns.
The technical mechanism behind this vulnerability involves the improper processing of decrypted TLS records where the decrypted payload has a length of zero bytes. When tls_sw_read_sock() encounters such a record, it passes the empty data to the read_actor function which returns zero indicating no data consumption. The kernel's processing loop interprets this zero return as backpressure condition, causing the socket buffer (skb) containing the empty record to be requeued at the head of the rx_list queue. This creates an infinite loop where the same empty record continuously gets processed and requeued, effectively blocking all subsequent legitimate TLS records from being processed.
This operational impact represents a severe denial-of-service scenario that can completely halt TLS communication on affected systems. The vulnerability affects any Linux kernel implementing the software-based TLS stack, particularly impacting services that rely on secure communications such as web servers, email servers, and other network applications using TLS 1.3. The flaw creates a condition where legitimate traffic becomes queued behind empty records, leading to complete communication paralysis for the affected connection.
The fix implemented addresses this by mirroring the behavior of tls_sw_recvmsg() which properly handles zero-length records by copying nothing and falling through to consume_skb(). This approach ensures that empty records are recognized early in the processing pipeline before the read_actor is invoked, allowing them to be consumed immediately and permitting subsequent records to proceed. The solution follows established patterns within the kernel's networking stack and maintains compatibility with the TLS 1.3 specification requirements while preventing the queue stall condition.
This vulnerability maps to CWE-400, specifically denoting an Uncontrolled Resource Consumption weakness where system resources become exhausted due to improper handling of empty data records. From an ATT&CK perspective, this represents a denial-of-service attack vector that can be exploited by remote adversaries to disrupt network services through carefully crafted TLS traffic patterns. The fix demonstrates proper resource management practices and aligns with kernel security best practices for handling edge cases in cryptographic protocol implementations.