CVE-2025-39964: Linux Kernel AF_ALG Race Condition Lands on CISA KEV With a Three-Day Deadline

TL;DR

CVE-2025-39964 is a race condition in the Linux kernel's AF_ALG cryptographic socket interface (CWE-362) that lets concurrent writes to the same socket interleave data unpredictably and corrupt the socket's internal state. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-18 with a remediation due date of 2026-09-21, so federal agencies and anyone aligning to BOD 26-04 have roughly a weekend to act. Apply the upstream af_alg_sendmsg patches (or your distribution's backported kernel), reboot, and — if you cannot patch immediately — restrict or blacklist the af_alg module for untrusted workloads.

What is this vulnerability?

Field	Value
CVE	CVE-2025-39964
Vendor / Product	Linux / Kernel (crypto subsystem, AF_ALG)
Vulnerability name	Linux Kernel Race Condition Vulnerability
Weakness	CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization)
CISA KEV added	2026-09-18
CISA KEV due date	2026-09-21
Known ransomware use	Unknown
Public exploit reference	GitHub PoC repository (see Exploitability)
Required action	Apply mitigations per vendor instructions; follow BOD 26-04 and CISA Forensics Triage Requirements

CISA's KEV entry describes the flaw plainly: the Linux kernel "contains a race condition vulnerability which allows concurrent writes to the same AF_ALG socket causing data to be unpredictably interleaved and creating inconsistencies in the socket's internal state." The upstream fix commit is titled "crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg."

Overview

CVE-2025-39964 lives in the kernel's AF_ALG interface, the socket family that exposes kernel cryptographic operations (hashes, ciphers, AEAD, RNG) to user space. The vulnerability was disclosed publicly on October 13, 2025, and resolved in the upstream crypto subsystem, with backports landing across multiple stable kernel branches — CISA's reference list points to seven separate stable commits, which tells you how widely the fix had to be propagated. That breadth matters for defenders: the same CVE identifier maps to dozens of distribution kernels, from Debian and Ubuntu to Red Hat, SUSE, Amazon Linux, Oracle Linux, Photon, Alibaba Cloud Linux, CBL-Mariner, Chainguard, Bottlerocket, and others cataloged by Wiz.

Severity signals diverge, and that divergence is worth understanding rather than averaging away. A vendor-supplied CVSS 3.1 vector scores the issue 7.8 (HIGH) with a local attack vector, low complexity, low privileges, no user interaction, and high confidentiality, integrity, and availability impact. NVD's own vector scores it 5.5 (MEDIUM), reflecting only availability impact. Wiz's public CVE page also lists 5.5 (MEDIUM). The gap is not noise — it reflects genuine disagreement about whether state corruption in a crypto socket can be shaped into confidentiality or integrity loss, or whether the realistic outcome is a crash or denial of service. For planning purposes, treat the higher vector as the ceiling and the lower one as the floor.

Why should defenders care about a local race condition that most scanners will rank as medium? Three reasons. First, CISA does not add CVEs to KEV casually; the listing on 2026-09-18 with a due date of 2026-09-21 signals observed exploitation or imminent risk in federal and critical infrastructure environments. Second, the attack surface is enormous — the Linux kernel is in everything, including container hosts, appliances, and embedded devices that are notoriously slow to patch. Third, AF_ALG is exactly the kind of interface that multi-tenant and container platforms expose to untrusted code without thinking about it, which turns a "local" bug into a cross-boundary problem.

Technical details

The root cause is the absence of write serialization in af_alg_sendmsg. AF_ALG sockets are stateful: a caller opens a socket, binds it to an algorithm, and then sends data through it. Nothing in the vulnerable code prevented two threads or processes from writing to the same socket at the same time. When that happens, the data buffers interleave in an order neither writer controls, and — more seriously — the shared socket context (ctx) can be mutated concurrently, producing inconsistencies in internal state such as buffer offsets, message-length tracking, and operation sequencing.

The upstream fix introduces a new ctx->write field that grants exclusive ownership for writing, effectively serializing sendmsg calls on a given socket. The kernel maintainers' position is blunt: issuing two writes to the same AF_ALG socket was always bogus, and the patch enforces correct usage rather than repairing a subtle logic error.

Key technical facts for triage:

• Vulnerable component: Linux kernel crypto subsystem, AF_ALG socket family (af_alg_sendmsg).
• Weakness class: CWE-362, race condition / improper synchronization on a shared resource.
• Attack vector: Local (AV:L). The attacker needs the ability to open an AF_ALG socket and issue concurrent writes.
• Privileges required: Low (PR:L) — a normal user account is typically sufficient, unless the distribution restricts AF_ALG via seccomp, LSM policy, or module blacklisting.
• User interaction: None (UI:N).
• Network exposure: AF_ALG is a local socket family, not a network service. There is no port to scan. Exposure comes from who can run code on the host — including containers, CI runners, and multi-tenant workloads.
• Affected versions: Any kernel built with AF_ALG support that predates the backported fix. Because the fix was propagated to many stable branches, the authoritative answer for your fleet is your distribution's advisory, not a single upstream version number. Check the seven stable commits CISA references against your kernel's changelog.
• Trust boundary crossed: User space to kernel cryptographic state. A local attacker influences kernel memory handling through a legitimate, documented API.

Impact

On the CIA triad, the vendor vector claims high impact across confidentiality, integrity, and availability. The realistic abuse scenarios break down as follows:

• Availability / denial of service. The most defensible outcome. Concurrent writes corrupt socket state, which can lead to kernel warnings, oopses, or panics. On a host running services that depend on kernel crypto — VPN terminators, TLS accelerators, disk encryption paths, container runtimes — a crash is a service outage.
• Integrity loss. Interleaved data means cryptographic operations may produce incorrect results. Applications that trust AF_ALG output for authentication tags, key derivation, or encrypted streams could accept or emit corrupted material without an obvious error.
• Confidentiality exposure. The higher vendor vector implies that state corruption could be shaped into disclosure of sensitive material processed through AF_ALG. This is the least certain of the three outcomes, but it is the one that justifies treating the CVE as more than a nuisance crash bug.
• Container and multi-tenant risk. In containerized environments, a compromised container with AF_ALG access may be able to affect host kernel state depending on configuration and namespace isolation. This is the scenario that turns a local bug into a platform-level problem.
• Privilege escalation potential. If state corruption can be reliably shaped into a memory-safety primitive, escalation becomes possible. The public PoC reference suggests researchers have at least explored the exploitation path.

Business exposure includes regulatory scrutiny under BOD 26-04, unplanned service outages, and integrity loss in workloads that depend on kernel cryptographic primitives. For regulated entities, the KEV listing itself creates a documentation obligation: you must be able to show either remediation or a documented, risk-accepted compensating control.

Exploitability

• KEV status: Listed 2026-09-18; remediation due 2026-09-21. This is a three-day window, which is unusually tight and implies active or imminent exploitation.
• EPSS: Watchstack reports an EPSS score of 0.0079 (percentile 0.54718). Wiz's public page lists an EPSS percentile of 25.6. These are low absolute numbers — consistent with a local-access bug that is not being mass-exploited by opportunistic botnets — but EPSS measures broad exploitation likelihood, not targeted risk. A KEV listing overrides a low EPSS for prioritization purposes.
• Public exploit / PoC: One public reference is indexed — a GitHub repository (n1k0oowang/CVE-2025-39964_EXP). Treat the existence of public tooling as a signal that the barrier to entry is falling, even if the current exploit is unreliable or environment-specific.
• In-the-wild context: CISA's KEV addition is the authoritative signal here. The KEV entry does not attribute the exploitation to a specific actor, and known ransomware use is listed as "Unknown." Do not infer a ransomware linkage that the sources do not state.
• Exploitation prerequisites: Local code execution as a low-privileged user, plus the ability to open an AF_ALG socket. On hosts where AF_ALG is restricted by seccomp or LSM policy, the prerequisite is not met — which is precisely why those controls are the recommended workaround.

KEV vs CVSS vs EPSS

Signal	What it measures	Action for this CVE
CISA KEV	Confirmed exploitation in the wild (or imminent risk) against federal/critical infrastructure	Highest priority. Remediate by 2026-09-21 or document an approved compensating control.
CVSS 3.1 (vendor, 7.8 HIGH)	Technical severity assuming local access, low privileges, full CIA impact	Use as the planning ceiling. Justifies emergency change windows and cross-team escalation.
CVSS 3.1 (NVD, 5.5 MEDIUM)	Technical severity with availability-only impact	Use as the floor. Do not let a medium score deprioritize a KEV-listed CVE.
EPSS (0.0079 / ~55th percentile)	Probability of exploitation activity in the next 30 days across the whole population	Low. Useful for backlog triage, not for overriding KEV.
Public PoC availability	Ease of weaponization by less-skilled actors	Raises urgency. Assume tooling will improve.

Exploitation steps (defensive triage)

These steps are written for defenders validating exposure and verifying remediation. They are not an exploit guide.

1. Inventory vulnerable kernels. Query your CMDB, EDR, and cloud inventory for Linux hosts, container hosts, and appliances. Map each to its distribution advisory for CVE-2025-39964 and confirm whether the backported fix is present. Do not rely on a single upstream version number.
2. Determine AF_ALG exposure. On representative hosts, check whether the af_alg module is loaded (lsmod | grep af_alg), whether /proc/crypto shows kernel crypto algorithms in use, and whether seccomp profiles, SELinux/AppArmor policy, or module blacklists restrict AF_ALG for unprivileged users.
3. Identify who can reach it. Enumerate workloads that run untrusted or multi-tenant code — containers, CI runners, build systems, shared jump hosts. These are your realistic attack paths, not internet-facing services.
4. Hunt logs and telemetry. Search kernel logs for warnings, oopses, or panics referencing af_alg, af_alg_sendmsg, or crypto socket internals. Use auditd or eBPF telemetry to look for concurrent sendmsg calls to the same AF_ALG file descriptor from multiple threads.
5. Check for exploit tooling. Scan developer and build systems for the public PoC repository and related artifacts. Presence of exploit code is not proof of compromise, but it changes your risk posture.
6. Patch and reboot. Apply your distribution's patched kernel package and reboot — kernel fixes do not take effect on a running system. Verify the running kernel version post-reboot.
7. Apply compensating controls where patching lags. Restrict AF_ALG via seccomp, SELinux, or AppArmor; blacklist the af_alg module where it is not required; and ensure untrusted containers cannot reach it.
8. Validate and document. Confirm that concurrent writes to a single AF_ALG socket are now rejected or serialized, record the verification evidence, and update incident response playbooks with AF_ALG race condition indicators.

Indicators of compromise

• Unexpected or repeated creation of AF_ALG sockets by processes that have no legitimate cryptographic workload.
• Kernel warnings, oopses, or panics referencing af_alg, af_alg_sendmsg, or crypto socket internals.
• Auditd or eBPF telemetry showing concurrent sendmsg calls to the same AF_ALG file descriptor from multiple threads.
• Container escape attempts or privilege escalation activity correlated with crypto socket usage.
• Anomalous CPU spikes in kernel crypto threads or softirq handling.
• Log entries showing corrupted or failed cryptographic operations in applications that use AF_ALG.
• Presence of known exploit tooling or PoC repositories (for example, the indexed GitHub reference) on developer or build systems.
• Unusual seccomp violations or attempts to bypass AF_ALG restrictions.

Mitigation and workarounds

Primary remediation. Apply the upstream kernel patches referenced in the stable tree commits, which add the ctx->write field and disallow concurrent writes in af_alg_sendmsg. In practice, this means installing your distribution's updated kernel package and rebooting. Confirm the fix is present across cloud instances, on-prem hosts, container hosts, and embedded devices — the long tail of Linux deployments is where KEV deadlines usually slip.

Compensating controls when patching is delayed. Red Hat's guidance, reflected in the Wiz reference material, is to prevent the af_alg module from loading by blacklisting it. This is effective but not free: workloads that legitimately depend on kernel crypto via AF_ALG will break, so validate before rolling it out broadly. Additional controls include seccomp filters that deny AF_ALG socket creation for untrusted processes, SELinux or AppArmor policies that restrict access, and container runtime configuration that prevents AF_ALG from being exposed to untrusted containers.

Isolation hygiene. Ensure user namespaces are properly isolated and that multi-tenant platforms do not hand AF_ALG to tenants by default. This is a durable control that reduces exposure to this CVE and to future kernel crypto bugs.

Compliance. Follow CISA BOD 26-04 guidance for prioritizing security updates based on risk, and comply with CISA's Forensics Triage Requirements. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines. For cloud services, follow applicable BOD 26-04 guidance or discontinue use of the product if mitigations are unavailable.

Verification. After patching, re-scan with your vulnerability management tooling, confirm the kernel version, and test that concurrent writes to a single AF_ALG socket are rejected or serialized. Document the evidence — KEV remediation is an auditable event.

Community reactions

Vendor advisories and security media have framed CVE-2025-39964 as a reminder that kernel crypto interfaces remain a subtle and under-monitored attack surface. The KEV addition with a three-day deadline has drawn attention from federal agencies and critical infrastructure operators, prompting urgent patch cycles. Community discussion has centered on how difficult AF_ALG abuse is to detect with conventional tooling, and on the value of seccomp and LSM policies in reducing exposure. Researchers have noted that while a public PoC exists, in-the-wild exploitation may be limited to targeted scenarios because of the local access requirement. The kernel maintainers' message was unambiguous: concurrent writes to AF_ALG sockets were always invalid, and the fix enforces correct usage.

FAQ

Is CVE-2025-39964 in the CISA KEV catalog? Yes. CISA added it on 2026-09-18.

What is the remediation due date? 2026-09-21 — a three-day window from the KEV addition.

Is this vulnerability internet-facing? Not directly. AF_ALG is a local socket family, so there is no port to scan. Exposure depends on who can run code on the host, including containers and multi-tenant workloads.

Which products are affected? The Linux kernel crypto subsystem (AF_ALG). Because the fix was backported across many stable branches, affected products include the major Linux distributions and cloud-optimized images — Debian, Ubuntu, Red Hat, openSUSE, Amazon Linux, Oracle Linux, Photon, Alibaba Cloud Linux, CBL-Mariner, Chainguard, Bottlerocket, and others.

Does it require privileges to exploit? The CVSS vector indicates low privileges (PR:L) and local access (AV:L). A normal user account is typically sufficient unless AF_ALG is restricted by seccomp, LSM policy, or module blacklisting.

Is there a public exploit? Yes — one public PoC repository is indexed. CISA's KEV listing is the stronger signal that exploitation has been observed or is imminent.

How do I verify remediation? Confirm your running kernel version includes the backported fix, re-scan with vulnerability management tooling, and test that concurrent writes to a single AF_ALG socket are rejected or serialized.

What if I cannot patch before the deadline? Apply compensating controls: blacklist the af_alg module where it is not required, restrict AF_ALG via seccomp or LSM policy, and isolate untrusted workloads. Document the control and the risk acceptance.

Related resources

• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 Implementation Guidance: Forensics Triage Requirements
• NVD: CVE-2025-39964
• Linux kernel stable commit 0f28c4adbc4a
• Linux kernel stable commit e4c1ec11132e
• Linux kernel stable commit 1f323a48e9b5
• Linux kernel stable commit 7c4491b5644e
• Linux kernel stable commit 9aee87da5572
• Linux kernel stable commit 45bcf60fe49b
• Linux kernel stable commit 1b34cbbf4f01
• Wiz vulnerability database: CVE-2025-39964