Wind River Support Network

Description

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

CREATE(Triage):(User=admin) [CVE-2025-39682 (https://nvd.nist.gov/vuln/detail/CVE-2025-39682)