Linux Kernel TLS Zero-Length Record Handling Vulnerability (CVE-2025-39682) Advisory
Executive & SecOps Summary
SECOPS ASSESSMENTLinux systems utilizing in-kernel TLS (ktls) offload or software implementation.
Remote attackers can trigger memory corruption or kernel panic, potentially leading to full system compromise (RCE).
Immediately update the Linux kernel to the latest stable version provided by your distribution.
Affected Products & Version Scope
Remediation & Live Workaround Commands
PATCH & WORKAROUND- Update Kernel: Apply the latest security patches from your OS vendor.
# For Ubuntu/Debian
sudo apt-get update && sudo apt-get upgrade linux-image-generic
# For RHEL/Fedora
sudo dnf update kernel- Reboot: A system reboot is mandatory to load the new kernel image.
- Temporary Mitigation: If patching is delayed, consider disabling the
tlskernel module if it is not a critical dependency for your applications.
# Check if tls module is loaded
lsmod | grep tls
# Unload the module (Caution: may break applications using ktls)
sudo modprobe -r tlsBlock Kernel Privilege Escalation & Ransomware Payloads Before You Can Reboot
Protect unpatched Windows, Linux, and macOS workloads against in-memory exploitation and lateral movement with autonomous EDR.
Technical Root Cause & Exploitation Mechanics
This vulnerability stems from a logic error (CWE-754) in the Linux kernel's TLS implementation when handling zero-length records on the rx_list. The recvmsg() function is designed to process either a sequence of contiguous DATA records or a single non-DATA record. In TLS 1.3, the record type is unknown until decryption. A critical flaw occurs during zero-copy decryption: since data is decrypted directly into the user-space buffer, no skb (Socket Buffer) remains to be queued. If the kernel encounters a zero-length record from the rx_list in this state, it fails to correctly manage the transition between record types, leading to inconsistent kernel states. Given its inclusion in the CISA KEV and a high EPSS score, this vulnerability represents a significant risk for remote exploitation.
Official Vendor Advisories & References
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.
Subscribe to Daily Vulnerability Briefings & KEV Alerts
Concise morning briefings for SecOps, DevSecOps, and SRE teams covering newly exploited CVEs and mitigation priorities.