ZeroDayAlert

CVE-2025-39682: Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability

Linux Kernel contains an improper check for unusual or exceptional conditions vulnerability in the TLS receive path which allows a zero-length record retrieved from the rx_list to bypass the intended recvmsg() record-type handling, potentially causing subsequent TLS records to be processed using incorrect zero-copy and queuing assumptions. The impacted product(s) could be end-of-life (EoL) and/or end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.

Linux Kernel Added to KEV 2026-09-18 Federal due 2026-09-21 Known ransomware use

Required action — quoted from CISA

Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

Where this comes from. The identifier, product, dates and required action above are copied verbatim from the CISA Known Exploited Vulnerabilities catalog. The action plan below is written by an AI agent from that record and published automatically. AssurePort has not independently tested this vulnerability and makes no claim about whether any specific system is affected.

Who is affected

Linux Kernel systems running versions affected by a TLS receive-path handling defect are potentially exposed. The vulnerability allows a malformed zero-length TLS record to circumvent record-type validation, causing subsequent records to be processed with incorrect assumptions about zero-copy and queuing behaviour. The record notes that affected versions may include end-of-life or end-of-service kernels; you should establish which kernel versions your organisation runs before determining whether discontinuation or patching is the appropriate path.

How to check whether this touches you

  • Inventory which Linux systems you operate and obtain their kernel versions via uname -r or distribution package managers; document any that are no longer receiving vendor support.
  • Establish whether these systems handle TLS traffic directly (servers running OpenSSL, BoringSSL, wolfSSL or similar TLS stacks) or whether the kernel TLS offload feature is enabled via grep -i tls /proc/sys/net/ipv4/tcp_ulp_memory_per_socket or similar kernel parameter inspection.
  • Confirm reachability of TLS services from outside your network perimeter by scanning from an external vantage point or reviewing firewall rules.
  • Check kernel module load state and TLS-accelerated socket usage via lsmod | grep tls and netstat/ss output for sockets using kernel TLS (marked with 'tls' in the socket protocol field on newer kernels).
  • Cross-reference your kernel version against Linux security advisories and your distribution's support lifecycle to determine patch availability.

What to do

  1. Do not wait for a fully automated patch: immediately review the CISA BOD 26-04 guidance and your organisation's internet-facing asset register to prioritise systems by exposure and criticality.
  2. For systems that cannot be patched immediately, disable kernel TLS offload (if enabled) and ensure TLS termination happens in userspace; document this mitigation in your asset register.
  3. If your kernel version is end-of-life, begin procurement and testing of a supported distribution or kernel version now, and plan a migration date within your incident response window.
  4. Enable comprehensive logging of TLS handshake failures and record-processing errors on affected systems; forward these logs to a central SIEM if available.
  5. Apply patches from your Linux distribution vendor as soon as they become available, following your change control process; verify the patch version against vendor release notes to confirm it addresses CVE-2025-39682.
  6. Escalate to your security steering group if you identify internet-facing systems running unsupported kernels for which no patch will be issued; discontinuation or replacement may be mandatory.

If you find you were exposed

Exploitation of this vulnerability requires an attacker to send a crafted TLS record to an affected kernel; review TLS handshake logs, connection logs, and any anomalous process behaviour dating back at least ninety days before the patch was applied. Malformed record injection may appear as repeated TLS errors, connection resets, or segfaults in userspace TLS libraries; cross-correlate these events with external access logs and firewall records to identify the source. Check whether any privileged process crashes or memory corruption events coincide with unusual inbound TLS traffic. Log retention is your constraint here; if logs have already been rotated, document the gap and prioritise live monitoring going forward.

Get these the morning they land.

One email, only when a vulnerability is newly confirmed as exploited — the CISA record plus our action plan. No more than one a day, and nothing on quiet days.

Knowing it exists is not the same as knowing you are exposed.

This page can tell you that CVE-2025-39682 is being exploited. It cannot tell you whether Kernel is running somewhere of yours that is reachable. That question is what a scan answers.

Check your own surface →