CVE-2025-39682 — Linux kTLS zero-length rx_list record UAF

This tracker is no longer updated. It was published on 2026-09-20, two days after CISA added CVE-2025-39682 to its Known Exploited Vulnerabilities catalog, as a record of when each distribution shipped the year-old fix: every tracked row was already fixed or not affected, so there is nothing left to watch. Versions and dates below are as of 2026-09-20.

Summary

⚠️ CISA reports active exploitation — a year after the fix shipped. The kernel fix landed in August 2025 and reached every affected upstream stable line in the same week; every distribution row tracked here has since shipped it or was never affected. The remaining exposure is hosts still booting a kernel built before autumn 2025, and especially hosts that terminate TLS in the kernel — NFS over TLS, and web or proxy servers with kTLS turned on. Compare the running kernel with the First fixed column for its distribution and reboot into a fixed build; where that is not possible today, block the tls module or disable kTLS in the application until it is.

How the exploitation chain works

kTLS lets the kernel decrypt TLS records on the receive path and hand plaintext straight to recvmsg(). Each recvmsg() call is allowed to return either any number of contiguous DATA records or exactly one non-DATA record (an alert, a handshake message, application-defined control data): the record type is reported through cmsg, so records of different types must never be merged into one call. When the next record turns out to have a different type from what the call has already returned, the receive loop stops. Under TLS 1.3 the type is only known after decryption, so a record that has already been decrypted but does not fit the current call is queued on rx_list, and the next recvmsg() starts by draining that list.

A second rule interacts with the first. DATA records may be decrypted zero-copy, straight into the caller’s buffer, in which case there is no plaintext sk_buff left to queue; the code relies on the fact that a non-DATA record always ends the loop, so a zero-copy record can never be followed by one that would have to be queued. The corner case the code missed is a call whose first record comes from rx_list and is zero length: nothing was copied, so the “already returned a non-DATA record” test — written as copied && control != TLS_RECORD_TYPE_DATA — did not fire, the loop carried on into the main decrypt path with zero-copy still permitted, and a following record of the other type was handled on the assumption that it could be queued when it could not.

From that point the kTLS record parser’s bookkeeping is wrong. Per the kernel CNA’s scoring rationale, the parser’s anchor sk_buff is queued on rx_list after the TCP receive queue behind it has already been released, so the next recvmsg() copies freed kernel heap into the user buffer; the live anchor is consumed while the parser still uses it, after which incoming attacker-controlled TCP bytes are written into the freed buffer; and socket teardown double-frees the anchor and its fragment list. Any of these corrupts slab state reliably enough to crash the kernel on demand, and the write-after-free is the kind of primitive that control-flow hijacks are built from. The remote peer chooses the record sequence, so the whole trigger is driven from the wire.

The fix, 62708b9452f8, is a handful of lines: it treats content type 0 as “no type reported yet” and stops the loop whenever a non-DATA record has been seen — control && control != TLS_RECORD_TYPE_DATA — so a zero-length first record no longer defeats the check.

ℹ️ kTLS in use is the gate. The vulnerable code runs only for sockets that have the TLS ULP attached with receive keys installed. A kernel that merely has CONFIG_TLS built, or the tls module loaded, is not reachable until some application (a kTLS-enabled web server, NFS over TLS, a kTLS-enabled client library) sets it up. On such a host the peer needs no privileges and no user interaction, which is why the kernel CNA scores it network-reachable and critical while NVD, scoring the impact on the socket owner, calls it local. Only the kernel backport flips a verdict below; blocking the module or disabling kTLS is a mitigation, never a fix.

Vulnerable commit range

The reachable window is therefore 6.0 through 6.16.3 (and 6.17 before -rc3). A kernel is safe by carrying the fix or by predating the v6.0 parser rewrite.

Patch status

A row is Fixed only if its kernel carries the 62708b9452f8 fix — a release at or past its branch’s first-fixed version, or an explicit distro backport. The fix reached every affected upstream stable line on 2025-08-28, and the lines cut since then (6.18, 7.0, 7.1, 7.2) have carried it from their first release. Every tracked distribution has shipped it too, most of them in September or October 2025, so the table below is a record of when each row was fixed rather than a watch list — the operator’s question is whether a given host has actually rebooted into one of those builds. The 5.15 and 5.10 upstream lines, and Rocky Linux / RHEL 8, predate the vulnerable code and are Not affected.

The first group is the upstream kernel; the rest are a focused set of x86-64 distributions, with per-distribution detail in the sections that follow. Current kernel is what each row shipped when this tracker was archived (2026-09-20); First fixed and Fixed since name the first fixed build and the day it shipped.

Linux kernel

The fix reached Linus in v6.17-rc3 (tagged 2025-08-24), four days after it was posted, and the stable maintainers carried it to every affected line in the 2025-08-28 point releases: 6.16.4, 6.12.44, 6.6.103, and 6.1.149. The 6.16 line has since reached end of life (final release 6.16.12, 2025-10-12) but every release from 6.16.4 onward carries the fix, so a host pinned to 6.16.y stays fixed as long as it is at or past 6.16.4. The same holds for the 6.17 and 7.0 lines, which were cut after the fix landed and have since gone EOL: every release on them is fixed.

Every line still maintained at archival (2026-09-20) is fixed or out of window. The 6.18, 7.1, and 7.2 branches were all cut from a mainline that already carried the fix, so they have been fixed since their first release; 7.1.y has since reached end of life at 7.1.13, still fixed. 5.15.y and 5.10.y predate the v6.0 record-parser rewrite that introduced the vulnerable path — the old shared strparser code does not have this bug — so they are not affected and receive no backport.

To verify a tree directly, look for the control && control != TLS_RECORD_TYPE_DATA test in tls_sw_recvmsg() (net/tls/tls_sw.c); a vulnerable kernel has copied && control != TLS_RECORD_TYPE_DATA there instead.

Debian

Debian’s sid, forky, trixie, and bookworm all shipped the fix in September 2025. sid took the fixed 6.16.5-1 upload on 2025-09-08, and forky (testing, the future Debian 14) became fixed when 6.16.7-1 migrated on 2025-09-17 — the first fixed kernel to reach the suite. trixie (Debian 13) and bookworm (Debian 12, under LTS) were fixed on the same day, 2025-09-22, by DSA-6008-1 (6.12.48-1, trixie-security) and DSA-6009-1 (6.1.153-1, bookworm-security) respectively.

bookworm also offers a newer kernel through bookworm-backports (the linux source package rebuilt from trixie’s 6.12 line); its first fixed build, 6.12.57-1~bpo12+1, entered the archive on 2025-11-06, and the 6.12.43 backport before it was vulnerable — a host that installed the backports kernel in autumn 2025 and has not updated since is still on it. A separate linux-6.12 source package for bookworm is queued in Debian’s NEW queue at a version well past the fix, but has not been accepted into the archive and cannot be installed yet.

bullseye (Debian 11) reached the end of its LTS window on 2026-08-31 and no longer receives updates. Its default 5.10 kernel predates the vulnerable code, and its linux-6.1 opt-in kernel was fixed by DLA-4328-1 (2025-10-13, 6.1.153-1~deb11u1) while the suite was still supported — a bullseye host is exposed only if it opted into 6.1 and never took that update.

Proxmox VE

Proxmox ships its own Ubuntu-derived kernels, so Debian’s status does not carry over, and Proxmox VE is x86-only. No PVE changelog names CVE-2025-39682: the fix arrived silently inside routine rebases onto Ubuntu sources that already carried it (Ubuntu fixed the 6.8 line in 6.8.0-86.87 and the 6.14 line in 6.14.0-34.34, both in autumn 2025).

PVE 9’s default kernel has carried the fix since 6.14.11-3-pve (2025-09-22), the first proxmox-kernel-6.14 build rebased onto a fixed Ubuntu 6.14 source, back when 6.14 was the PVE 9 default. The default has since moved to proxmox-kernel-6.17 and then to proxmox-kernel-7.0, both of which are based on upstream releases that already contained the fix, so every PVE 9 default kernel since September 2025 is fixed.

PVE 8’s default proxmox-kernel-6.8 has carried the fix since 6.8.12-16-pve (2025-10-14), the first build rebased onto Ubuntu 6.8.0-88.89. PVE 8 also offers proxmox-kernel-6.14 as a bookworm-backports opt-in, fixed since 6.14.11-5-bpo12-pve (2025-12-15, rebased onto Ubuntu 6.14.0-37.37); Proxmox stopped updating that series in May 2026, but every build from -5 onward is fixed.

Both releases still publish older preview series that Proxmox abandoned without ever rebasing past the fix — PVE 8’s proxmox-kernel-6.2, 6.5, and 6.11 — and a host still booting one of those is vulnerable until it switches to its release’s current default. PVE 9’s superseded proxmox-kernel-6.17 and proxmox-kernel-6.14 series are both fixed (6.17 from its first build, 6.14 from 6.14.11-3).

NixOS

Every tracked ref’s default linuxPackages is linux_6_18, a series that has carried the fix since its first release, so every tracked NixOS ref is fixed — and has been since long before the current default. When the fix shipped, in August 2025, the default was linux_6_12: nixpkgs master picked up 6.12.44 on 2025-08-28, and the channels republished it within two days (nixos-unstable-small the same day, nixos-unstable and nixpkgs-unstable on 2025-08-30). The release-26.05 branch and its nixos-26.05 / nixos-26.05-small channels were created in May 2026 from a master that had carried the fix for nine months, so they have been fixed from their first publication.

nixpkgs also pins linux_6_1, linux_6_6, and linux_6_12 at or above their branches’ first-fixed releases, so a host that overrides boot.kernelPackages to an older LTS is fixed too, as long as it tracks a current-enough ref; linux_5_15 and linux_5_10 are not affected.

Rocky Linux / RHEL family

RHEL-family kernels are long-lived forks, and the base version says little about exposure: Red Hat had backported the v6.0 kTLS parser into RHEL 9’s 5.14 kernel, so RHEL 9 and RHEL 10 were affected, while RHEL 8’s 4.18 kernel never received it and is not affected (Red Hat records the vulnerable code as not present). Red Hat rates the flaw Moderate (CVSS 7.0) and fixed both affected releases on 2025-09-29: RHSA-2025:16880 for RHEL 9 (kernel-5.14.0-570.49.1.el9_6) and RHSA-2025:16904 for RHEL 10 (kernel-6.12.0-55.37.1.el10_0), with matching kernel-rt errata. Rocky Linux rebuilt them as RLSA-2025:16880 (2025-10-10) and RLSA-2025:16904 (2025-10-07), and its current kernels are far past those builds; AlmaLinux and Oracle Linux track the same RHSAs.

Red Hat’s own advice for a host that cannot yet reboot is to prevent the tls module from loading (see Mitigation below). The kernel-rt real-time kernel shares the base kernel’s status in every release.

Amazon Linux

All three AL2023 kernel streams are fixed. ALAS2023-2025-1186 (2025-09-10) fixed the default kernel stream (6.1 line) at 6.1.150-174.273.amzn2023, and ALAS2023-2025-1208 (2025-09-23) fixed the kernel6.12 opt-in stream at 6.12.46-66.121.amzn2023. The kernel6.18 opt-in stream was introduced with the AL2023.10.20260302 release on 2026-03-02, at a version that already carried the fix, so it has never shipped a vulnerable build. Amazon Linux 2 reached end of support on 2026-06-30 and is not tracked.

Detection

Is the running kernel in the affected window and missing the fix? Compare the running kernel against the Patch status table’s First fixed column for its distribution and series — a distro kernel below its first-fixed build is vulnerable, whatever its upstream version number looks like:

uname -r

Is kTLS receive actually in use? The kernel keeps per-namespace counters once the tls module is loaded; a non-zero TlsCurrRxSw or TlsCurrRxDevice means sockets are decrypting TLS in the kernel right now, and the file being absent means the module is not currently loaded:

cat /proc/net/tls_stat

Is the tls module loaded or built in? lsmod shows a loaded module; a kernel with CONFIG_TLS=y has it built in and no lsmod line:

lsmod | grep '^tls'

Which services could be attaching it? kTLS is opt-in per application. The usual suspects are NFS mounts and exports with TLS (xprtsec=tls or xprtsec=mtls), web and proxy servers with kTLS enabled (nginx ssl_conf_command Options KTLS, HAProxy’s ktls, OpenSSL-based servers setting SSL_OP_ENABLE_KTLS), and the tlshd handshake daemon that NFS over TLS needs (its presence in /etc/tlshd.conf or as a running service is itself the tell):

grep -rilE 'ktls|xprtsec|tlshd' /etc/nginx /etc/haproxy /etc/exports /etc/fstab 2>/dev/null

Public PoC

There was no public exploit for this bug when this tracker was archived (2026-09-20). The kernel’s own selftest, added the same day as the fix (a61a3e961baf, selftests: tls: add tests for zero-length records in tools/testing/selftests/net/tls.c), sends the triggering record sequence over a loopback kTLS socket and reproduces the fault deterministically on a vulnerable kernel, so anyone with the source can build a trigger; that it is a one-shot, race-free trigger is why the kernel CNA scores it low complexity. CISA’s KEV entry states that it is being exploited but publishes no details. Treat it as exploited-in-practice: patch, or apply the mitigations below.

Mitigation

The real fix is a patched kernel (a release at or past its line’s First fixed version, or the distro build named in the table). Until the host has rebooted into one, the exposure can be removed by keeping kTLS from being used — none of these is a fix, and all of them cost the performance kTLS was turned on for.

Block the tls module

Where nothing on the host needs kernel TLS, blocking the module closes the path for every application at once. install … /bin/false is surer than a plain blacklist, which only suppresses alias autoloading:

echo 'install tls /bin/false' | sudo tee /etc/modprobe.d/cve-2025-39682.conf

That rule prevents future loads only. If the module is already resident but no socket is using it, unload it so the block takes effect now:

sudo rmmod tls

A module that is genuinely in use cannot be unloaded — rmmod refuses, and the services holding kTLS sockets have to be stopped or switched to userspace TLS first. The rule is likewise inert on a kernel with CONFIG_TLS=y built in; check with lsmod and the TlsCurr* counters above. On NixOS, the equivalent is a module option:

boot.extraModprobeConfig = "install tls /bin/false";

Disable kTLS in the application

Where the host does need TLS but not kernel TLS, turn kTLS off in the consumer and it falls back to userspace crypto: ssl_conf_command Options -KTLS in nginx, dropping SSL_OP_ENABLE_KTLS in OpenSSL-based services, xprtsec=none (or plain unencrypted transport) for NFS mounts and exports, and stopping the tlshd handshake daemon where nothing else depends on it.

Limit who can reach kTLS listeners

Because the attacker is the remote peer, a kTLS server is exposed to every client that can complete a handshake — including anonymous ones, before any application-level authentication. Until patched, keep kTLS listeners off untrusted networks and behind allow-lists; a kTLS client is exposed to any server it connects to, so pin it to trusted endpoints.

Risk notes

• Kernel TLS terminators are the exposure. NFS over TLS, and web or proxy servers with kTLS enabled, expose the receive path to every remote peer that can complete a TLS handshake; the trigger is a three-record sequence with no race and no privileges. Hosts that never attach kTLS are not reachable.
• This is a stale-kernel problem, not a missing-fix problem. Every tracked distribution shipped the fix between August 2025 and March 2026, so a currently-updated host is fixed; the hosts CISA’s deadline is aimed at are the ones that have not rebooted into a kernel from the last year. Check uname -r against the First fixed column, not the date of the last apt upgrade.
• The scores disagree on purpose. The kernel CNA’s 9.8 reflects the remote, unauthenticated peer; NVD’s 7.1 and Red Hat’s 7.0 score the impact on the socket owner and the kTLS-in-use precondition. Both are right about different hosts: a kTLS-serving host should read the 9.8.
• Old kernels are safe by age here. Unlike many kernel CVEs, this one has a hard lower bound: 5.15.y, 5.10.y, and RHEL 8’s 4.18 kernel predate the v6.0 kTLS parser rewrite and are not affected, and the kernel CNA, Ubuntu, and Red Hat all record them so.
• Backports available (CVE-2025-39682): the fix has landed in mainline 6.17-rc3 and stable 6.16.4, 6.12.44, 6.6.103, and 6.1.149, and every line cut since (6.18, 7.0, 7.1, 7.2) has carried it from its first release; distro kernels that have not adopted one of those remain vulnerable.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the git reference, advisory, or repository index that established each fact — so any row can be audited or reproduced. Most readers never need it.

References