CVE-2025-39682 — Kernel
CRITICALCVE-2025-39682 is a critical-severity (CVSS 9.8) CWE-754 vulnerability in Kernel. It is in CISA's Known Exploited Vulnerabilities catalog (added 2026-09-18) — treat it as actively exploited and patch now. A fix is available for Kernel — see the affected versions and patch details below.
tls: fix handling of zero-length records on the rx_list
Exploitation Status
Actively exploited in the wild
- Confirmed by CISA's Known Exploited Vulnerabilities catalog on 2026-09-18. Federal agencies were required to remediate by 2026-09-21.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA (KEV catalog and SSVC triage) for CVE-2025-39682.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
KernelReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Linux packages — download data is not available via public APIs for these ecosystems.
Description
In the Linux kernel, the following vulnerability has been resolved:
tls: fix handling of zero-length records on the rx_list
Each recvmsg() call must process either
- only contiguous DATA records (any number of them)
- one non-DATA record
If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rx_list. Next recvmsg() will pick it up from there.
Queuing the skb to rx_list after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).
Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rx_list, and it's zero length.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐧Linux | Kernel | ≥ 6.0.0&&< 6.1.149 | 6.1.149 |
Affected Products
debian linuxdebianlinux kernellinuxsimatic cn 4100 firmwaresiemensResearch use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Kernel, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update Kernel to 6.1.149 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-39682 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
A logic bug in the kTLS receive path mishandles zero-length records taken from the rx_list, allowing a mixed record-type sequence to slip past the per-recvmsg() type constraint and proceed to data processing. The fix initializes and checks the per-call content type (using 0 as “unset”) and bails out when a non-DATA…
To mitigate this issue, prevent module tls from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.Source: Red Hat security advisory for CVE-2025-39682 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Enterprise Linux 10 | kernel-0:6.12.0-55.37.1.el10_0 | RHSA-2025:16904 |
| Red Hat Enterprise Linux 9 | kernel-0:5.14.0-570.49.1.el9_6 | RHSA-2025:16880 |
| Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions | kernel-0:5.14.0-284.144.1.el9_2 | RHSA-2025:19224 |
| Red Hat Enterprise Linux 9.2 Update Services for SAP Solutions | kernel-rt-0:5.14.0-284.144.1.rt14.429.el9_2 | RHSA-2025:19223 |
| Red Hat Enterprise Linux 9.4 Extended Update Support | kernel-0:5.14.0-427.96.1.el9_4 | RHSA-2025:19104 |
Frequently Asked Questions
Is CVE-2025-39682 in your dependencies?
Find it across Linux, including transitive dependencies.