Linux Kernel CVE-2025-39682: Patch Now If You Use kTLS

A correction first. CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog on 18 September 2026, not two.

Our article that day covered CVE-2025-39964 and CVE-2026-53266, and missed the third one added in the same batch: CVE-2025-39682. If you patched only the two we listed, the third one — with the same deadline of today, 21 September — is still open on your systems.

CVE-2025-39682 is a flaw in the kernel TLS (kTLS) receive path. The remediation is the same as for the other two: confirm a fixed package exists for your release, install it, then reboot.

First: does this affect you at all?

This only matters where kernel TLS receive is actually in use. On a typical web server, TLS is handled in userspace by OpenSSL or similar and kTLS is not enabled.

But do not settle that from memory. kernel.org, the CNA, names the exposed consumers explicitly: OpenSSL-with-kTLS servers and clients, NFS-over-TLS, and SMB/RPC-over-TLS via net/handshake. Environments that carry storage or file sharing over TLS can be in scope without anyone having decided to turn kTLS on.

What to do now

• ✓Check whether kTLS receive is in use. The kernel's own documentation states that per-namespace statistics are exposed at `/proc/net/tls_stat`. `TlsCurrRxSw` and `TlsCurrRxDevice` are the RX sessions currently installed (host-side and NIC-side cryptography respectively), and `TlsRxSw` and `TlsRxDevice` are the cumulative totals opened. A non-zero cumulative count means it has been used.
• ✓Check whether your release is fixed. Use the distribution trackers linked below and read the row for your release and your kernel flavour (generic, aws, azure and so on). `Fixed` means an update closes it; `Not affected` means that kernel is out of scope.
• ✓If you are affected, update and reboot. A kernel update does not take effect until you reboot — until then the old image is still running.
• ✓Confirm the reboot took. `uname -r` shows the running kernel; compare it against the package version you installed.
• ✓Handle the other two from 18 September as well. CVE-2025-39964 and CVE-2026-53266 share today's deadline. All three are separate fixes; closing one does not close the others.
• ✓Check for end-of-life kernels. For this CVE too, CISA notes the affected product could be EoL/EoS, in which case it advises discontinuing use or moving to a supported version.

Three assessors, three different answers (9.8 / 7.1 / 7.0)

On this CVE the assessors disagree not just on severity but on the attack vector itself. These are the values we read on 21 September 2026.

• ▸kernel.org (the CNA): 9.8 CRITICAL — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`. Network (AV:N)
• ▸NIST (NVD Primary): 7.1 HIGH — `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H`. Local (AV:L)
• ▸Red Hat: 7.0, with a threat severity of Moderate — `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H`. Network, but high attack complexity (AC:H)

The box above carries NIST's 7.1, because that is the primary assessment on NVD. Do not take it at face value.

NVD's status for this record is "Undergoing Analysis", last modified 19 September 2026, so the value can still move. It already did on a sibling: CVE-2025-39964, added to KEV the same day, was raised from 3.3 LOW to 5.5 MEDIUM when NIST completed its analysis on 19 September — we published the 3.3 figure and had to correct it afterwards.

And in this case kernel.org's reasoning is the more concrete of the two.

kernel.org records, in the CVE itself, why it chose each metric value. For `AV:N` it writes that "the bug is triggered entirely by the sequence and content of TLS records arriving from the remote peer on a kTLS-enabled TCP socket (net/tls RX path); no local access is needed", and for `PR:N` that "the attacker is the remote TLS peer, which holds no privileges on the target system".

That is a different premise from NIST's `AV:L`. We are not going to adjudicate which is right, but note the asymmetry: kernel.org states its reasoning, and CISA has listed the CVE as actively exploited with a due date.

How CISA reads it

Alongside the KEV entry, CISA attached an SSVC decision dated 18 September 2026: Exploitation: active, Automatable: yes, Technical Impact: total.

The entry also carries `forensicTriage: Yes`, and the required action points at BOD 26-04 together with CISA's "Forensics Triage Requirements". Known ransomware campaign use is listed as "Unknown".

What actually goes wrong

The defect is in how the kTLS receive path handles zero-length records.

Each `recvmsg()` call must process either only contiguous DATA records or a single non-DATA record. When the record type changes the loop breaks, and an already-decrypted record is queued to `rx_list` for the next call. A record decrypted with zero-copy cannot be queued, because it was written straight into the userspace buffer — so the code assumed you can never zero-copy and then discover the record type changed. That assumption breaks when the first record taken from `rx_list` has zero length.

Per kernel.org, the attacker sends three back-to-back records — `[DATA]`, `[zero-length non-DATA]`, `[DATA]` — and the corruption occurs deterministically while the victim runs its ordinary `recvmsg()` loop, with no race to win and no memory-layout dependency; the kernel selftest added with the fix reproduces it in one shot. TLS 1.2 is zero-copy-capable by default, so no unusual kernel configuration or socket option is required.

kernel.org describes the consequences as freed kernel heap copied straight into the userspace buffer (a kernel memory disclosure primitive), attacker-controlled write-after-free and freelist corruption, and a double free of already-released skbs producing oopses and panics. The weakness class is CWE-754 (improper check for unusual or exceptional conditions).

The fix is over a year old; the news is the exploitation

CVE-2025-39682 was published on 5 September 2025, and the fix went upstream then.

So as with the other two from 18 September, this is not a newly discovered hole — it is a hole that was already patched being confirmed as used in real attacks. Which also means: the longer a server has gone without a reboot, the more exposed it is.

Distribution status as of 21 September 2026

Unlike the other two, the fixes for this one have landed across the major LTS releases. This is what we read on 21 September 2026.

Ubuntu (main `linux` package): 24.04 LTS noble is `Fixed 6.8.0-86.87` and 25.04 plucky is `Fixed 6.14.0-34.34`. 22.04 LTS jammy, 20.04 LTS focal and 18.04 bionic are `Not affected`, as are 26.04 resolute and 25.10 questing.

Debian: bookworm fixed in `6.1.153-1` (DSA-6009-1), trixie fixed in `6.12.48-1` (DSA-6008-1). Bullseye needs care. The `linux` source package is marked `(not affected)`, but the `linux-6.1` source package IS affected and is fixed in `6.1.153-1~deb11u1` (DLA-4328-1). If you run a 6.1 kernel on bullseye, you are in scope. Check the source package you actually have installed, not just the release name.

Red Hat: threat severity Moderate. RHEL 10 lists `kernel-6.12.0-55.37.1.el10_0` and RHEL 9 lists `kernel-5.14.0-570.49.1.el9_6`. RHEL 6, 7 and 8 are `Not affected`.

Do not read that as "older is safe, newer is exposed". Ubuntu 22.04 on 5.15 is `Not affected`, while Debian bookworm on 6.1 is affected and has a fix — what matters is how far the offending change was carried into each stable series.

These are the main packages. Flavours such as `linux-aws` and `linux-azure` carry their own status, so read the row for the flavour you actually run.

Debian bullseye is the clearest example. Within one release, `linux` and `linux-6.1` give opposite answers. Stopping at "my release says not affected" can leave you running an unpatched kernel.

Why we missed the third one

The cause was how we queried KEV. Writing the 18 September article, we fetched CISA's KEV feed and then looked up a set of CVE identifiers we had already decided on. The third addition from that day never entered the result. The file we downloaded contained all three from the start.

Searching for what you expect and listing what was actually added are different operations, and we only did the first. From now on we filter the feed by date, count the entries, and choose the subject afterwards.

The 18 September article has been corrected from "two" to "three" and now points here.

Confidence, and what is not covered

• ▸All three CVSS values were read directly from their primary sources on 21 September 2026. NVD is still "Undergoing Analysis", so its value can change.
• ▸No workarounds are given. Improvised kernel configuration changes or module unloading create their own outages. Whether kTLS can be disabled is a question for the software that enabled it.
• ▸Exploitation techniques and detection signatures are out of scope. A KEV listing establishes that a flaw was used in real attacks, not who achieved what.
• ▸The `/proc/net/tls_stat` counter names come from the kernel's own documentation. Which counter maps directly onto the conditions for this defect is not documented, so we do not claim it.