🔒 kTLS Zero-Length Record Advisory

kTLS zero-length record bug: remote memory disclosure or crash in the Linux kernel TLS receive path
CVE-2025-39682     CVSS 9.8 Critical (NVD)     published September 5, 2025     Ubuntu priority: Medium     Red Hat CVSS 7.0     On CISA's Known Exploited list since 2026-09-18

This bug is in kTLS, the part of the kernel that can encrypt and decrypt TLS traffic on a TCP socket for an application. A malformed TLS 1.3 sequence involving a zero-length record can slip past a type check, which can lead to a kernel memory disclosure or a crash. It only matters on machines where an application actually uses kernel TLS.
Versions and advisories below were checked on 2026-10-01 against the Ubuntu CVE tracker, Red Hat's CVE data and NVD (read through a summarising tool, so re-check a number against the vendor page before you rely on it). A kernel NEWER than the one listed also contains the fix.
Defensive notes only: no exploit code here. Only run the mitigation on machines you own or administer.
IMPORTANT: NVD's CISA fields list this CVE in CISA's Known Exploited Vulnerabilities catalog (added 2026-09-18, due date 2026-09-21). Treat it as "being used in the wild": patch, do not just mitigate.

NVD and the Linux kernel CNA score it 9.8 (network, no privileges, no user interaction, high impact on everything).
Red Hat scores it 7.0 because it judges the attack as hard to pull off (attack complexity High) and the impact narrower. Ubuntu's own priority is just Medium.
None of them is "wrong": they weigh how likely a real attacker is to get it to work. The practical question is not the number but "does this machine use kTLS?"

Normally a program (a web server, a proxy) does the TLS encryption itself in user space. With kTLS the program hands the encryption keys to the kernel, and the kernel encrypts and decrypts on the socket. It is faster, and it is switched on per connection by the application.
In TLS 1.3 the kernel only learns the real type of a record after it has decrypted it. The bug is in how a zero-length record sitting in a waiting list (rx_list) was handled: a mixed sequence of record types could get past the rule that one recvmsg() call must only return one type, and the kernel carried on processing data it should have stopped on.
The fix (kernel commit titled "tls: fix handling of zero-length records on the rx_list") makes the kernel handle that case correctly.

Only machines where BOTH are true: the tls kernel module is loaded, and some program really turns kTLS on for its sockets (for example a web server or proxy configured for it, or a custom application).
Ubuntu:          24.04 (kernel 6.8, and 22.04 running the 6.8 HWE kernel), and 25.04. Ubuntu's tracker lists many older releases as not affected: check yours on the tracker.
Red Hat family:  RHEL 9 and RHEL 10 (and their EUS/E4S streams). RHEL 6, 7 and 8 are NOT affected.
Others:          Debian, SUSE, Amazon Linux and rebuilds published their own advisories.
Lower risk:      machines that do not use kTLS (most of them). Still patch: the CVE is on the known-exploited list.

Module   What it is                                     Where it lives
tls      Kernel TLS (kTLS) support for TCP sockets      A loadable module on Ubuntu and RHEL (it loads when a program asks for it)
What breaks if you block it: programs that ask the kernel to do TLS for them (kTLS offload) lose that option and fall back to ordinary user-space TLS in most software. Ordinary HTTPS keeps working. Test first on anything that really uses kTLS.

uname -r                                          # the kernel you are running RIGHT NOW (compare with the tables below)
lsmod | grep -w tls                               # is the module loaded? (prints nothing if not)
cat /proc/net/tls_stat 2>/dev/null                # exists only when the module is loaded; TlsCurrRxSw / TlsCurrTxSw above 0 means a program is using kTLS right now
grep -r "KTLS" /etc/nginx 2>/dev/null             # nginx can use kTLS (ssl_conf_command Options KTLS;): other servers have their own switches
ls /etc/modprobe.d/ | grep -i tls                 # any block file already installed
No module loaded and nothing using it is a good sign, but a program can load the module on demand, so mitigate or patch anyway.

Manual mitigation (only if you cannot patch yet; Red Hat's published advice is to stop the tls module loading)
1. Block the module from loading:
   echo "install tls /bin/false" | sudo tee /etc/modprobe.d/manual-disable-tls.conf
2. Unload it if it is loaded (errors hidden if it is not; it will refuse if a program is using it):
   sudo rmmod tls 2>/dev/null
3. Verify:
   grep -qE '^tls ' /proc/modules && echo "tls module is loaded" || echo "tls module is NOT loaded"
   modprobe -n -v tls                                          # should print: install /bin/false
Red Hat says "blacklist the module" (its solution article 41278). A plain "blacklist" line only stops automatic loading by alias; the "install ... /bin/false" form also stops a program from loading it by name, which is why this guide uses it.
If a program was using kTLS, restart it (or reboot) so it falls back to user-space TLS.
Undo it later, after you have installed the patched kernel and rebooted into it:
   sudo rm /etc/modprobe.d/manual-disable-tls.conf
   sudo reboot

Ubuntu:
   sudo apt update && sudo apt upgrade
   sudo reboot
Red Hat / RHEL:
   sudo dnf upgrade --refresh 'kernel*'
   sudo reboot
A kernel update does nothing until you boot into it. Run uname -r afterwards and compare with the tables below.
Already installed the Copy Fail kernels from the Copy Fail guide? For Ubuntu 22.04 and 24.04 those are newer than the ones below, so you are covered here too.

Patched kernels: Ubuntu (first fixed versions; anything newer is also fixed)
Release              Kernel line              Fixed in
24.04 LTS Noble      Linux 6.8                6.8.0-86.87
22.04 LTS Jammy      Linux 6.8 (HWE)          6.8.0-86.87~22.04.1
25.04 Plucky         linux (6.14)             6.14.0-34.34        (25.04 is end-of-life: move to a supported release)
24.04 Noble cloud/special kernels (first fixed):
   linux-aws 6.8.0-1041.43     linux-azure 6.8.0-1041.47     linux-gcp 6.8.0-1042.45     linux-oracle 6.8.0-1038.39
   linux-gke 6.8.0-1038.43     linux-lowlatency 6.8.0-86.87.1     linux-nvidia 6.8.0-1041.44     linux-azure-nvidia 6.8.0-1029.32
Ubuntu's tracker marks many older releases (for example 20.04 and 18.04 kernels) as not affected. Look yours up on https://ubuntu.com/security/CVE-2025-39682.

Patched kernels: Red Hat Enterprise Linux (kernel package; "or newer" applies)
RHEL 10 (10.0 stream)   6.12.0-55.37.1.el10_0              (RHSA-2025:16904, Sept 29 2025)
RHEL 9  (9.6 stream)    5.14.0-570.49.1.el9_6              (RHSA-2025:16880, Sept 29 2025)
RHEL 9.4 EUS            5.14.0-427.96.1.el9_4              (RHSA-2025:19104, Oct 27 2025)
RHEL 9.2 E4S            5.14.0-284.144.1.el9_2             (RHSA-2025:19224, Oct 29 2025)
RHEL 6, 7 and 8: not affected.
Newer streams (RHEL 9.7, 9.8, 10.1, 10.2) ship newer kernels than these, so a current kernel contains the fix.
Rebuilds (AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux) use their own package numbers: follow their advisories, not this table.

Is my kernel patched?
Ubuntu:
   uname -r                                                         # compare with the Ubuntu table above
   apt changelog linux-image-$(uname -r) | grep CVE-2025-39682      # the changelog should mention the CVE
   pro fix CVE-2025-39682 --dry-run                                 # Ubuntu Pro client: says whether this machine is fixed
Red Hat / RHEL:
   uname -r                                                         # compare with the RHEL table above
   rpm -q --changelog kernel-$(uname -r) | grep CVE-2025-39682      # the changelog should mention the CVE
   sudo dnf updateinfo list --cve CVE-2025-39682                    # which advisory fixes it and whether it is installed
   sudo needs-restarting -r                                         # says whether a reboot is still needed
Careful: rpm -q kernel and dpkg -l 'linux-image*' list INSTALLED kernels, including old ones you are not running. Only uname -r tells you what is actually running.

rmmod says "Module tls is in use": a program is using kTLS. Stop that program, or just patch and reboot.
modprobe -n -v tls prints nothing useful: the block file is missing, is not named *.conf, or is not in /etc/modprobe.d/.
Web server errors after blocking the module: the server was configured to REQUIRE kTLS. Turn that option off in its config (for nginx, remove the KTLS option) or patch instead of blocking.
I updated but uname -r shows the old kernel: you have not rebooted yet. The patch only counts once the new kernel is running.
A cloud image shows a kernel name like 6.8.0-1041-aws: cloud kernels have their own fixed numbers. Do not compare them with the generic 6.8.0-86 line.

Know whether you use kTLS. Most servers do not, and for them this is a "patch on the normal schedule, but do it this week" item. For the few that do (busy proxies, file servers, custom TLS code) it moves up the list.
Patch and reboot beats blocking every time. Treat the block as a temporary bandage and remove it afterwards.
Prioritise internet-facing machines that terminate TLS first: that is where a remote bug matters.
The module name is "tls", which is also a very common word. When you search your logs, search for "tls_" or the module list, not just "tls", unless you enjoy 40,000 results.
Put the date and reason in a comment inside any block file you create. "Why does this box not use kTLS?" is a bad mystery at 2 a.m.
Zero-length records carry no data, which makes it a little rude that they caused this much trouble.

Ubuntu CVE tracker:     https://ubuntu.com/security/CVE-2025-39682
Red Hat CVE page:       https://access.redhat.com/security/cve/cve-2025-39682
Red Hat CVE data feed:  https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-39682.json
NVD entry:              https://nvd.nist.gov/vuln/detail/CVE-2025-39682
Red Hat module blacklist how-to: https://access.redhat.com/solutions/41278