Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-39682

CVE-2025-39682: Linux Kernel TLS Handling DoS Flaw

CVE-2025-39682 is a denial of service vulnerability in the Linux kernel's TLS implementation affecting zero-length record handling on rx_list. This article covers the technical details, affected versions, security impact, and mitigation.

Published:

CVE-2025-39682 Overview

CVE-2025-39682 is a Linux kernel vulnerability in the Transport Layer Security (TLS) subsystem. The flaw affects handling of zero-length records on the rx_list in the kernel's tls receive path. The issue stems from a corner case where an initial record pulled from rx_list is zero-length, breaking assumptions the recvmsg() logic makes about zero-copy decryption and record type transitions. A local, authenticated user can trigger the condition to affect confidentiality and availability on the host. The vulnerability has been resolved upstream and backported to affected stable kernels, with Debian and Siemens issuing coordinated advisories.

Critical Impact

Local authenticated users can trigger memory disclosure or denial-of-service in the kernel TLS receive path by exploiting mishandled zero-length records on rx_list.

Affected Products

  • Linux kernel (multiple stable branches, including 6.17-rc1 and 6.17-rc2)
  • Debian Linux 11 (Bullseye)
  • Siemens products bundling affected Linux kernel versions (see Siemens SSA-032379)

Discovery Timeline

  • 2025-09-05 - CVE-2025-39682 published to the National Vulnerability Database (NVD)
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-39682

Vulnerability Analysis

The vulnerability resides in the kernel TLS (kTLS) receive path, specifically in how recvmsg() processes records queued on the rx_list. Each recvmsg() invocation must process either contiguous DATA records or a single non-DATA record. When record types differ, the kernel breaks out of the processing loop and queues the pending record on the rx_list for the next call.

Zero-copy decryption complicates this flow. In zero-copy mode, the kernel decrypts ciphertext directly into a user-space buffer and does not retain an skb for the plaintext. Only DATA records are permitted zero-copy handling, so the code assumes a type change cannot occur after zero-copy has begun.

The fix addresses a corner case the original logic missed: when the initial record originates from rx_list and has zero length, the assumptions break down. This mishandling can lead to incorrect state on the receive queue and potential kernel-side impact on confidentiality and availability [CWE-Other].

Root Cause

The root cause is incomplete input validation in the TLS receive loop for zero-length records queued on rx_list. The kernel did not correctly account for a zero-length pending record when deciding whether zero-copy decryption was safe, allowing state assumptions to be violated during subsequent processing.

Attack Vector

Exploitation requires local, authenticated access with the ability to establish a kTLS socket and manipulate record framing on the receive path. The attacker crafts a TLS traffic pattern that leaves a zero-length record queued on rx_list, then triggers a recvmsg() call that enters the vulnerable code path.

No public proof-of-concept exploit is available. The Exploit Prediction Scoring System (EPSS) probability is 0.178%.

No verified exploit code is available. Refer to the upstream kernel commits for the exact patch diff and reproducer conditions: Kernel commit 3439c15a.

Detection Methods for CVE-2025-39682

Indicators of Compromise

  • Unexpected kernel oops, warnings, or panics referencing tls_sw, tls_rx, or recvmsg in dmesg and /var/log/kern.log.
  • Local processes repeatedly opening kTLS sockets and issuing atypical recvmsg() patterns against short or zero-length TLS records.
  • Anomalous kernel memory usage or process crashes on hosts running kTLS-enabled workloads such as NFS-over-TLS or user-space TLS offload.

Detection Strategies

  • Inventory Linux hosts running kernel versions predating the fix commits (2902c3eb, 29c0ce3c, 3439c15a, 62708b94, c09dd377) and prioritize patching.
  • Monitor kernel logs for TLS subsystem warnings and correlate with process telemetry to identify local users triggering the code path.
  • Use vulnerability scanners with up-to-date NVD feeds to flag kernels matching the affected CPE ranges.

Monitoring Recommendations

  • Enable persistent kernel log collection and forward to a central log store for retention and correlation.
  • Track process-to-syscall behavior for uses of setsockopt(TCP_ULP, "tls") combined with unusual recvmsg patterns.
  • Baseline normal kTLS workloads to make deviations from expected record sizes and types easier to spot.

How to Mitigate CVE-2025-39682

Immediate Actions Required

  • Apply the vendor kernel update as soon as it is available for your distribution. Debian users should follow DLA-2025 October advisory.
  • Siemens customers should review Siemens SSA-032379 and apply firmware or software updates for affected industrial products.
  • Restrict local shell access on kTLS-enabled hosts to trusted administrators only.

Patch Information

The fix is available in upstream stable kernel commits 2902c3eb, 29c0ce3c, 3439c15a, 62708b94, and c09dd377. Reference the mainline commit for the patch content. Distribution-specific packages are available from Debian and downstream vendors including Siemens.

Workarounds

  • Where kTLS is not required, disable kernel TLS offload and keep TLS termination in user space until patched kernels are deployed.
  • Limit which local users and containers may create TCP sockets with the TCP_ULP "tls" option using Linux Security Modules or seccomp filters.
  • Isolate multi-tenant workloads that rely on kTLS on separate hosts to reduce blast radius until patches are applied.
bash
# Verify running kernel version and compare against fixed builds
uname -r

# Debian: install the fixed kernel and reboot
sudo apt update
sudo apt install --only-upgrade linux-image-$(uname -r | sed 's/.*-//')
sudo reboot

# Optional: block unprivileged use of TCP_ULP "tls" via seccomp in service units
# SystemCallFilter=~@obsolete

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.