CVE-2025-39964: Linux Kernel AF_ALG Socket Race Condition Corrupts Internal State

Background

AF_ALG is the Linux kernel’s cryptographic API socket family, exposing kernel-resident cipher, hash, and AEAD implementations to userspace applications through ordinary socket I/O (socket(), bind(), accept(), read()/write()). It allows userspace software to offload cryptographic operations to the kernel — useful for hardware-accelerated crypto or for applications that want to use kernel-provided implementations rather than linking their own crypto library.

Because AF_ALG is a kernel subsystem reachable by any process capable of creating a socket of that family, a vulnerability here has the potential to affect any Linux system where userspace software exercises this interface, which includes a range of cryptographic tooling and some containerized or sandboxed workloads that rely on in-kernel crypto.

Technical Mechanism

This vulnerability is classified as CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization — “Race Condition”).

The CISA KEV description states that concurrent writes to the same AF_ALG socket cause data to be “unpredictably interleaved,” creating “inconsistencies in the socket’s internal state.” Mechanically, this points to a missing or insufficient locking/synchronization guard around the code path that handles write operations to an AF_ALG socket’s internal buffers (such as scatter-gather lists, length counters, or pending-request queues). When two threads or processes write to the same socket concurrently without the kernel properly serializing access to that shared state, the operations can race: one write’s bookkeeping updates can be partially overwritten or observed out-of-order relative to another’s, leaving the socket’s internal data structures in a state the code was never designed to handle.

Race conditions of this kind in kernel code are not merely a correctness nuisance — because the corrupted state consists of pointers, length fields, and buffer references used by subsequent kernel operations on that same socket, an inconsistent state can manifest as the kind of corruption-adjacent conditions more commonly associated with memory-safety bugs (e.g., operations proceeding against a buffer whose recorded length or reference no longer matches reality). Depending on which specific fields are affected and how later code paths consume them, this can range from a crash (kernel panic / denial of service) to a condition exploitable as a memory-corruption primitive.

The public stable-tree fix commits referenced in the CISA KEV notes (seven individual commits across the kernel’s crypto subsystem) are consistent with a fix that adds or corrects synchronization around the affected write path; this article does not reproduce their exact diff content, as that level of code-level detail is best verified directly against the linked commits.

Real-World Exploitation Evidence

CVE-2025-39964 is listed in CISA’s Known Exploited Vulnerabilities (KEV) catalog, added on September 18, 2026, which is itself the confirming evidence of observed real-world exploitation — CISA adds entries to KEV only once active exploitation has been established.

The knownRansomwareCampaignUse field is recorded as “Unknown.” CISA has not confirmed this vulnerability has been used in ransomware operations; this status reflects the absence of public confirmation, not a confirmed absence of such use.

No specific threat actor, intrusion set, or named campaign has been publicly attributed to exploitation of this CVE in the data available for this article.

Impact Assessment

The affected CVSS score of 7.8 (high) is notable for a race-condition bug: scores in this range are typically associated with a local attack vector combined with high impact across confidentiality, integrity, and availability — a profile more consistent with a vulnerability that enables an unprivileged local process to meaningfully corrupt kernel state than with a pure crash-only denial-of-service bug (which would typically score lower on the availability-only axis).

Practically, this means organizations should treat the risk as spanning:

• Availability impact: A straightforward consequence — a kernel panic or crash from exercising the race, usable as a local denial-of-service primitive.
• Confidentiality/integrity impact: Less certain from the public description alone, but plausible given the CVSS tier — depending on precisely what data the corrupted socket state exposes or allows subsequent code to misuse, a sufficiently reliable trigger of this race condition in kernel-resident crypto-handling code could potentially be developed into a stronger primitive (information disclosure of adjacent kernel memory, or a foothold toward privilege escalation). Vuln Brief has not seen public exploit code or a detailed exploitation write-up confirming this stronger outcome, and this should be treated as a reasonable risk hypothesis based on CWE class and CVSS tier rather than a confirmed capability.

As an open-source kernel component, this affects any Linux distribution or embedded system running an unpatched kernel version that includes the vulnerable AF_ALG code, across server, desktop, container-host, and embedded/IoT deployments alike — essentially anywhere Linux runs and userspace has access to create AF_ALG sockets.

Affected Versions

Because this affects an open-source kernel component used across many distributions, there is no single vendor version matrix. The fix is delivered as a set of stable-tree commits rather than a single “patched version” number:

Organizations should check with their Linux distribution vendor (Red Hat, Canonical/Ubuntu, Debian, SUSE, etc.) for the specific kernel package version in which these commits were backported, rather than relying on upstream kernel version numbers alone.

Remediation Steps

1. Apply your distribution’s kernel security update that incorporates the fix commits referenced in the CISA KEV notes, then reboot into the patched kernel — a kernel fix does not take effect until the new kernel is actually running.

   # Debian/Ubuntu example
   sudo apt update && sudo apt upgrade linux-image-$(uname -r)
   sudo reboot

2. As a compensating control where immediate patching/reboot is not feasible, consider restricting which local users/processes can create AF_ALG sockets (for example via seccomp profiles, SELinux/AppArmor policy, or namespace restrictions in container runtimes), since exploitation requires the ability to open and write concurrently to such a socket.

3. Prioritize multi-tenant and container-host systems for patching, since these are the environments where an unprivileged local actor is most likely to already have the access needed to trigger the race.

Detection Guidance

• Kernel crash/panic logs: review dmesg, kernel oops reports, and crash dump data for panics or warnings originating in the AF_ALG/crypto subsystem.
• Process monitoring: flag processes that create AF_ALG sockets and issue high-frequency concurrent writes from multiple threads, as this is the precondition for triggering the race — though legitimate crypto-offload usage may also exhibit some concurrent access, so this signal requires tuning to avoid false positives.
• Patch-level inventory: maintain an accurate inventory of running kernel versions/patch levels across the fleet so unpatched systems can be identified quickly once a backport date is known for your distribution.

Precise detection signatures were not available in the source material for this article; defenders should consult distribution-specific security advisories for any additional IOC guidance as it becomes available.

Timeline

References

• Linux stable-tree fix commit
• Linux stable-tree fix commit
• Linux stable-tree fix commit
• Linux stable-tree fix commit
• Linux stable-tree fix commit
• Linux stable-tree fix commit
• Linux stable-tree fix commit
• CISA BOD 26-04 — Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 Implementation Guidance — Forensics Triage Requirements
• NVD — CVE-2025-39964