CVE-2025-39682: Critical Linux Kernel KTLS Zero-Length Record Flaw

A critical flaw in the Linux Kernel TLS receive path, tracked as CVE-2025-39682, allows unauthenticated remote attackers to bypass socket record-handling logic and disrupt kernel memory state. The vulnerability stems from improper check conditions when handling zero-length TLS records inside the kernel’s TLS subsystem (KTLS). Systems offloading TLS processing directly to the kernel—such as high-throughput reverse proxies, edge load balancers, and container ingress nodes—face serious exposure if configured to consume KTLS socket infrastructure.

Mechanics of the KTLS Receive Path Flaw

Kernel TLS (tls.ko) enables user-space applications to delegate symmetric encryption and decryption directly to the Linux networking stack. When applications read decrypted payload data using recvmsg(), incoming TLS records are queued inside an internal kernel structure called rx_list.

The core issue in CVE-2025-39682 sits in how the kernel evaluates record types upon retrieval from rx_list. When a zero-length TLS record (such as an empty application data frame or malformed TLS control record) arrives, the receive state machine skips mandatory record-type validation. Because the zero-length payload bypasses normal checks, subsequent non-zero TLS records in the queue are evaluated under incorrect zero-copy and socket buffer (sk_buff) alignment assumptions.

This state confusion breaks the invariant guarantees that KTLS relies on for zero-copy memory management. An attacker sending a specially crafted sequence of zero-length frames followed by standard TLS records can cause kernel memory corruption, trigger a kernel panic, or potentially achieve remote code execution in the context of the host kernel.

Evaluating CVSS Metrics Against Real-World EPSS

The vulnerability carries a CVSS 3.1 score of 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). This reflects an unauthenticated, low-complexity attack path reachable over the network without user interaction. If a target host exposes a service using KTLS, an attacker only needs network access to the port to trigger the condition.

Despite the maximum CVSS score, current EPSS measurements place the 30-day probability of exploitation at 0.51% (the 42.1th percentile). This statistical gap exists because KTLS is not enabled globally across every standard Linux server; it requires user-space software (such as NGINX, HAProxy, or custom Async I/O daemons) to explicitly set the TCP_ULP socket option to use tls.

However, where KTLS is deployed, the attack vector is direct and high-impact. Defenders should treat this score gap as a reflection of deployment density rather than a sign that the underlying flaw is difficult to trigger.

Impacted Linux Kernel Versions

The vulnerability affects kernel releases spanning multiple long-term support (LTS) branches:

• Kernel 6.0 branches: Fixed in version 6.1.149
• Kernel 6.2 branches: Fixed in version 6.6.103
• Kernel 6.7 branches: Fixed in version 6.12.44
• Kernel 6.13 branches: Fixed in version 6.16.4
• Kernel 6.17 release tree: Vulnerable in initial build; patched in downstream stable updates

Legacy deployments, including Debian 11 environments using backported 6.x kernels, are also impacted. Users running legacy or End-of-Life (EoL) kernel releases that no longer receive upstream stable updates must transition to a supported kernel branch immediately.

Remediation and Mitigation Guidelines

To resolve CVE-2025-39682, system administrators should update their host kernels to the respective fixed stable releases or apply the vendor patches directly from the kernel source tree (upstream commits include 2902c3ebcca52ca845c03182000e8d71d3a5196f and 3439c15ae91a517cf3c650ea15a8987699416ad9).

Federal agencies and organizations subject to CISA BOD 26-04 guidance must ensure mitigations or updates are deployed prior to the September 21, 2026 remediation deadline.

If immediate kernel rebooting is not viable, the primary mitigation is to prevent the loading of the kernel TLS module. Unload or blacklist the module using modprobe:

echo "blacklist tls" > /etc/modprobe.d/disable-ktls.conf
modprobe -r tls

Disabling KTLS forces applications back to standard user-space TLS libraries (such as OpenSSL, BoringSSL, or rustls). While this removes kernel-level zero-copy performance gains, it completely isolates the host from the vulnerable rx_list execution path until kernel maintenance can occur.