CVE-2025-39682
Linux Kernel · Operating systems
Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability
At a glance
Exploited. Added to CISA’s catalog of exploited vulnerabilities on September 18, 2026.
CISA asks you to hunt for signs of compromise: patching is not enough if the device has already been breached.
Affected product: Linux Kernel (category Operating systems, indicative classification). Name in CISA’s catalog: Linux Kernel.
What should I do?
Apply the patches or mitigations from Linux; if none are available, stop using the product. Start with internet-facing devices.
CISA also asks you to hunt for signs of compromise: patching is not enough if the device has already been breached.
Deadline set by CISA for US federal agencies: 3 days (due September 21, 2026). It only binds those agencies, but it is a useful measure of urgency.
- Linux security advisories page (general page, not the advisory for this vulnerability)
- The vendor’s specific advisory is listed in the NVD references: CVE-2025-39682 on the NVD website.
Original text of the required action (CISA)
Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA's BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA's "Forensics Triage Requirements" (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.
Timeline
- Vulnerability published Publication date (NVD)
- Exploitation confirmed Added to CISA’s KEV catalog
- CISA deadline Remediation deadline set for US federal agencies
The facts, with their sources
- Exploitation confirmed
- Yes, on September 18, 2026 Date added to the catalog of exploited vulnerabilities. Exploitation itself may have started earlier. Source: KEV catalog, collected September 29, 2026 at 14:57 UTC
- Ransomware
- No known use to date That does not guarantee it is not being used: the information is not public. Source: KEV catalog, collected September 29, 2026 at 14:57 UTC
- Hunt for compromise
- Requested by CISA Source: KEV catalog, collected September 29, 2026 at 14:57 UTC
- CISA required action
- Apply the patches or mitigations from Linux; if none are available, stop using the product. Start with internet-facing devices. Rewritten by this site from CISA’s original text. Source: KEV catalog, collected September 29, 2026 at 14:57 UTC
- CISA deadline
- September 21, 2026, 3 days Set for US federal agencies: a measure of urgency, not an obligation elsewhere. Source: KEV catalog, collected September 29, 2026 at 14:57 UTC
- Vulnerability published
- September 5, 2025 Source: National Vulnerability Database (NVD), collected September 29, 2026 at 15:00 UTC
- Product according to CISA
- Linux Kernel Filed by this site under “Operating systems” (indicative classification). Source: KEV catalog, collected September 29, 2026 at 14:57 UTC
- CVSS vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Technical detail of the score: attack vector, complexity, impact. Source: National Vulnerability Database (NVD), collected September 29, 2026 at 15:00 UTC
Severity and activity
FIRST’s EPSS model. Since exploitation is already confirmed, this figure is mostly useful to compare activity. Collected Sep 29, 2026.
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.
Official description from the NVD, collected Sep 29, 2026. CVE® description © The MITRE Corporation.
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 end-of-service (EoS). Users are advised to discontinue use and/or transition to a supported version.
Summary from CISA (KEV catalog).
CERT-FR advisories
No advisory among the latest CERT-FR publications this site follows. That does not mean there are none.
Information reused under the Open Licence 2.0 (Etalab); the date of last update is shown for each advisory. This site is neither affiliated with nor endorsed by ANSSI.
Sources for this page
- CISA KEV catalog: exploitation, date added, required action, deadline, ransomware.
- NVD (NIST): CVSS severity, publication date, description, vendor references.
- EPSS (FIRST): probability of exploitation.
- CERT-FR: advisories and alerts (in French).
- Brand and category: indicative classification by this site (method).