CyberRota Analysis
AI-GeneratedThe vulnerability affects the Linux kernel's handling of zero-length TLS application data records, which can lead to a denial-of-service condition by causing a loop that blocks subsequent records from being processed. This issue arises when the `tls_sw_read_sock()` function fails to properly handle empty records, resulting in a requeueing mechanism that halts the processing of all following data. Organizations utilizing Linux systems with TLS 1.3 should prioritize addressing this vulnerability to prevent potential service disruptions.
Original NVD Description
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.