CVE-2025-39682: Linux Kernel TLS Receive Path Zero-Length Record Flaw Breaks recvmsg() Assumptions

Background

The Linux kernel’s in-kernel TLS (kTLS) implementation offloads TLS record framing and, in some configurations, encryption/decryption to the kernel rather than handling it entirely in userspace. This is used by high-performance networking stacks and applications (including some web servers and proxy software) that want to avoid the overhead of crossing the kernel/userspace boundary repeatedly for TLS record processing, and it integrates with zero-copy data paths that avoid extra memory copies for performance.

The TLS receive path specifically handles incoming encrypted records delivered to a socket using kTLS, decrypting them and making the resulting plaintext available to the calling application via recvmsg(). Because this code runs in kernel context and processes network-attacker-influenced data (the contents and framing of incoming TLS records), correctness bugs in this path carry outsized risk relative to equivalent bugs in userspace TLS libraries.

Technical Mechanism

CVE-2025-39682 is classified under CWE-754, Improper Check for Unusual or Exceptional Conditions. The kernel’s TLS receive path fails to properly check for an exceptional condition: a zero-length TLS record retrieved from the rx_list (the kernel’s internal queue of pending decrypted/pending records) is not correctly handled by the code path that enforces recvmsg() record-type semantics.

In kTLS, each decrypted record carries a record type (e.g., application data vs. the TLS alert/handshake types used internally), and recvmsg() logic relies on correctly identifying record boundaries and types as it walks the rx_list to return data to the calling application. When a zero-length record is allowed to slip through this check unhandled, the kernel’s internal bookkeeping for “where does this record start and end, and what type is it” becomes inconsistent with the actual queued data.

The kernel’s own description of the consequence is specific: this “bypass” causes “subsequent TLS records to be processed using incorrect zero-copy and queuing assumptions.” In a zero-copy data path, the kernel typically tracks data by reference (buffer pointers and lengths) rather than by copying it — if the length/offset bookkeeping for one record becomes wrong because of the zero-length record edge case, every subsequent record processed against that now-incorrect state risks being read from, or accounted against, the wrong buffer region or length. This class of bookkeeping corruption in a zero-copy kernel path is consistent with out-of-bounds memory access conditions (reading or referencing memory outside the intended record’s buffer), which is why this analysis classifies the vulnerability under the Memory Corruption category, while acknowledging that the kernel advisory language given does not state an explicit “overflow” or “use-after-free” term — it describes a queuing/zero-copy assumption violation whose downstream effect is consistent with that class of bug.

The affected kernel upstream fix commits (linked in the References section) touch the kTLS rx_list and recvmsg() record-type handling logic directly, which corroborates the mechanism described above.

Real-World Exploitation Evidence

CVE-2025-39682 was added to CISA’s KEV catalog on 2026-09-18, confirming active exploitation in the wild per KEV listing criteria. CISA set a remediation deadline of 2026-09-21 — a three-day window.

Notably, CISA’s entry for this vulnerability states that “the impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS),” and advises that “users are advised to discontinue use and/or transition to a supported version” where a fix is not available. This is a meaningful distinction from the other entries in this batch: remediation may not be as simple as “apply the patch” for every affected kernel version, since some affected kernel branches may no longer receive vendor/distribution support at all.

knownRansomwareCampaignUse is listed as “Unknown.” CISA has not confirmed ransomware campaign use of this vulnerability at this time.

No specific threat actor or campaign has been publicly attributed to exploitation of CVE-2025-39682 based on the data available for this analysis. Kernel vulnerabilities of this nature are frequently exploited for local privilege escalation or as part of a container-escape or sandbox-escape chain rather than as a standalone remote attack vector; this general pattern-matching is offered for risk context and is not an attribution claim about this specific CVE.

Impact Assessment

The CVSS score of 9.8 indicates attackers can achieve a complete confidentiality, integrity, and availability impact. Because the vulnerability lives in the kernel’s TLS receive path, and kTLS is a kernel-mediated feature that processes network-sourced data, the exploitation surface depends on how a given system uses kTLS:

• Memory-safety consequences in kernel context — a bookkeeping corruption affecting zero-copy buffer/queue state in kernel code carries the risk of out-of-bounds kernel memory access, which can translate to information disclosure (reading adjacent kernel memory into a TLS record delivered to an application), denial of service (kernel crash/panic), or — in the worst case, depending on exploitation sophistication — further memory corruption usable for privilege escalation
• Scope limited to kTLS-enabled sockets — systems and applications that do not enable in-kernel TLS offload for their sockets are not exposed to this specific code path, which narrows the practical attack surface to deployments that have explicitly opted into kTLS (common among high-throughput web/proxy servers and certain container networking stacks)
• EoL/EoS systems carry additional risk — because CISA flags that affected systems may be end-of-life, organizations running older, unsupported kernel branches with kTLS enabled face a situation where no vendor patch may ever be forthcoming

Sector-specific risk: Any organization running high-throughput network services (CDN edge nodes, reverse proxies, load balancers) that specifically enable in-kernel TLS offload for performance should treat this as a priority; organizations not using kTLS have a substantially narrower exposure window, though kernel-level memory safety issues always warrant attention given the difficulty of fully ruling out exploitation paths.

Affected Versions

The KEV data does not specify exact kernel version ranges, and notes that affected products could include end-of-life or end-of-service kernel branches. The linked upstream kernel stable-tree commits are the most concrete available reference for which code paths and kernel versions were patched:

Organizations should check their specific distribution’s kernel changelog/advisory for whether the fix has been backported to their running kernel version, since distribution kernels frequently diverge from upstream version numbering.

Remediation Steps

CISA’s required action is to apply mitigations per vendor instructions in compliance with BOD 26-04 and Forensics Triage Requirements, or to discontinue use of the product if mitigation is unavailable — explicitly relevant here given the EoL/EoS note.

1. Identify systems using in-kernel TLS offload (kTLS):

# List sockets currently using the TLS kernel module/ULP
ss -K -t -a 2>/dev/null || cat /proc/net/tls_stat 2>/dev/null
lsmod | grep -i tls

2. Check running kernel version against distribution security advisories for whether the fix corresponding to the linked upstream commits has been backported.
3. Apply the distribution-provided kernel update containing the fix, then reboot affected systems (kernel fixes require a reboot to take effect, unless live-patching infrastructure is in place).
4. For end-of-life or end-of-service kernel branches with no available patch, per CISA guidance: discontinue use of the affected product, or at minimum disable kTLS offload where operationally feasible as a stopgap, and prioritize migration to a supported kernel/distribution release.
5. Where live-patching (e.g., kpatch, Ksplice-style tooling) is available in the environment, apply the corresponding live patch to avoid extended exposure windows while scheduling a full reboot cycle.

Detection Guidance

No kernel-level vulnerability of this class typically has a simple network signature, since exploitation occurs inside kernel memory-handling logic rather than at a clearly fingerprintable protocol layer. Exact detection guidance should come from your Linux distribution’s security team and any kernel runtime integrity/eBPF-based monitoring tooling in use.

General indicators worth reviewing in the interim:

• Unexpected kernel panics, oops messages, or dmesg warnings referencing the TLS/kTLS subsystem (tls_sw_recvmsg, rx_list, or similar symbol names) on systems using kTLS
• Anomalous behavior in applications relying on kTLS zero-copy receive, such as corrupted or truncated application data inconsistent with network capture of the same session
• Where available, kernel runtime security monitoring (e.g., eBPF-based tooling) configured to alert on unusual memory-access patterns within the TLS receive code path
• Review /var/log/kern.log or journalctl -k for repeated anomalies on hosts with kTLS enabled, particularly preceding any service instability

Timeline

References

• Linux kernel stable fix commit — 2902c3ebcca5
• Linux kernel stable fix commit — c09dd3773b59
• Linux kernel stable fix commit — 3439c15ae91a
• Linux kernel stable fix commit — 29c0ce3c8cdb
• Linux kernel stable fix commit — 62708b9452f8
• CISA BOD 26-04 — Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 Implementation Guidance — Forensics Triage Requirements
• NVD — CVE-2025-39682