CVE-2025-39682

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: fix handling of zero-length records on the rx_list<br /> <br /> Each recvmsg() call must process either<br /> - only contiguous DATA records (any number of them)<br /> - one non-DATA record<br /> <br /> If the next record has different type than what has already been<br /> processed we break out of the main processing loop. If the record<br /> has already been decrypted (which may be the case for TLS 1.3 where<br /> we don&amp;#39;t know type until decryption) we queue the pending record<br /> to the rx_list. Next recvmsg() will pick it up from there.<br /> <br /> Queuing the skb to rx_list after zero-copy decrypt is not possible,<br /> since in that case we decrypted directly to the user space buffer,<br /> and we don&amp;#39;t have an skb to queue (darg.skb points to the ciphertext<br /> skb for access to metadata like length).<br /> <br /> Only data records are allowed zero-copy, and we break the processing<br /> loop after each non-data record. So we should never zero-copy and<br /> then find out that the record type has changed. The corner case<br /> we missed is when the initial record comes from rx_list, and it&amp;#39;s<br /> zero length.