Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability
TL;DR 📌
- 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…
- Highest CVSS: 9.8 (Critical).
- Listed in CISA KEV (2026-09-18) — this is being exploited in the wild.
- Fixed in
6.1.149,6.12.44,6.16.4,6.6.103— upgrade to this release or later. - CVEs: CVE-2025-39682.
What it is
CVE-2025-39682 is a flaw in the Linux kernel’s TLS receive path, specifically in the handling of zero-length records held on the rx_list.
The kernel’s TLS code enforces a rule for each recvmsg() call: process either a run of contiguous DATA records, or exactly one non-DATA record. When a decrypted record’s type differs from what’s already been processed, the loop breaks; if the record was already decrypted, it gets queued to rx_list for the next recvmsg() call to pick up.
The bug is that zero-copy decryption writes plaintext directly into the userspace buffer, with no skb to queue afterwards. The code assumes this scenario can’t coincide with a record-type change, because non-DATA records break the loop before zero-copy happens. The missed case is when the first record for a recvmsg() call comes from rx_list and is zero-length: this bypasses the type check that would normally prevent zero-copy handling, so subsequent records get processed under incorrect zero-copy and queuing assumptions.
The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, score 9.8) indicates this is reachable over the network without authentication or user interaction, and the impact spans confidentiality, integrity and availability. This is a kernel-level issue in TLS socket handling — any application relying on kernel TLS (kTLS) offload for its data plane is potentially affected. The CVE is listed in CISA’s KEV catalogue, so it is known to be exploited.
What to do
- Update to a kernel that includes the fix. NVD lists fixed versions 6.1.149, 6.6.103, 6.12.44, and 6.16.4 — check which of these applies to your kernel branch and upgrade accordingly.
- If you’re running a kernel older than these fixed releases and cannot patch immediately, review whether kernel TLS (kTLS) offload is in use on the affected hosts; this is the code path involved.
- Given the KEV listing, treat this as a priority patch rather than a routine kernel update — schedule it ahead of the normal maintenance cycle.
- If your kernel is end-of-life or end-of-service, note that no fix will be backported; plan a transition to a supported kernel line rather than waiting for a patch.
For leadership 🧭
Executive summary. Any Linux host using kernel TLS offload is exposed to a network-reachable, unauthenticated kernel flaw that can affect confidentiality, integrity and availability of data in transit, and it is already known to be exploited. Given its presence in CISA’s KEV catalogue, this needs patching ahead of the normal kernel maintenance cycle, not queued behind it.
Why it matters:
- The flaw sits in the kernel’s TLS receive path (kTLS), so any application offloading TLS decryption to the kernel is potentially affected, not just a specific userspace library or service.
- The CVSS vector shows no authentication or user interaction is required and the attack is network-reachable, with full impact across confidentiality, integrity and availability.
- It is listed in CISA’s KEV catalogue, meaning it is known to be exploited, which raises the urgency for hosts still running unpatched or end-of-life kernels.
- Systems on end-of-life or end-of-service kernel branches will not receive a backported fix and require a version transition rather than a simple patch.
Now / Next / Later:
- Now: ,
- Next:
- Later: