CVE-2025-39682
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-05

Last updated on: 2026-03-17

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: tls: fix handling of zero-length records on the rx_list Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there. Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length). Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-05
Last Modified
2026-03-17
Generated
2026-05-07
AI Q&A
2025-09-05
EPSS Evaluated
2026-05-05
NVD
CVE-2025-39682
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel 6.1.153
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's TLS implementation involves improper handling of zero-length TLS records on the receive list (rx_list). Specifically, the kernel expects each recvmsg() call to process either only contiguous data records or a single non-data record. However, a corner case was missed when the initial record comes from the rx_list and is zero-length. This can cause issues because zero-copy decryption is only allowed for data records, and the processing loop breaks after each non-data record. The vulnerability arises from the kernel not correctly handling zero-length records in this scenario, potentially leading to incorrect processing of TLS records.


How can this vulnerability impact me? :

The vulnerability could lead to incorrect processing of TLS records in the Linux kernel, which might affect the integrity or reliability of TLS communications. Since TLS is used to secure network communications, improper handling of records could potentially cause data corruption, unexpected behavior, or denial of service in applications relying on TLS. However, specific impacts such as data leakage or privilege escalation are not detailed in the provided information.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart