CISA deadline arrives for exploited Linux kernel AF_ALG race condition

CISA deadline arrives for exploited Linux kernel AF_ALG race condition

CISA's September 21 remediation deadline for CVE-2025-39964 should push this Linux kernel issue out of the ordinary backlog and into same-day verification. The bug sits in AF_ALG, the Linux kernel interface that lets user-space processes use kernel cryptographic operations, and CISA added it to the Known Exploited Vulnerabilities catalog after confirming active exploitation.

The important nuance is that this is not a remote unauthenticated edge-device bug. NVD rates the primary vector as local, and Red Hat describes a local user path to denial of service or corrupted cryptographic operation results. But local kernel bugs become more serious when an attacker already has a foothold through a compromised workload, a low-privileged account, a container escape attempt, or another post-exploitation path. That is why this belongs in vulnerability management queues that prioritize real attack chains, not just internet exposure.

What changed now

CISA added CVE-2025-39964 to KEV on September 18 and set September 21 as the due date for covered federal systems. The KEV record says the Linux kernel race condition allows concurrent writes to the same AF_ALG socket, causing data to be interleaved unpredictably and creating inconsistencies in the socket's internal state.

That short description matters because AF_ALG lives below the application layer. A user-space process does not need to exploit a web route directly to reach the vulnerable behavior if it can already execute locally. In practical terms, security teams should treat this as a kernel remediation and runtime-state validation problem: identify affected kernels, apply the vendor fix, and confirm that the fixed kernel is actually running after reboot or workload migration.

The timing also matters. CISA's deadline lands today, September 21, 2026. Even for organizations outside the federal mandate, KEV status is a useful signal that the issue has moved from theoretical patch debt to exploitation-informed response.

Why a local kernel flaw still matters

Local does not mean low risk. Many intrusions start with application compromise and then depend on privilege escalation to turn a narrow foothold into host control. Kernel flaws are attractive in that phase because they sit beneath user identities, service boundaries, and container abstractions.

Red Hat's advisory explains the core issue plainly: the AF_ALG datapath allowed two writers on the same socket, which could interleave request payloads and leave the per-socket context inconsistent. The fix introduces exclusive write ownership so only one writer can issue sendmsg() at a time.

For defenders, that means the risk is less about one exposed URL and more about every place where untrusted or semi-trusted code can run on Linux. Shared application hosts, developer workstations, build runners, container platforms, high-density virtualization hosts, and appliances that rely on vendor-supplied Linux kernels all deserve attention.

What defenders should verify first

Start with systems where local execution is plausible and business impact is high:

1. Internet-facing Linux workloads that could be reached through application compromise.
2. Container hosts and Kubernetes nodes running untrusted, multi-tenant, or high-change workloads.
3. CI/CD runners, build systems, and package infrastructure where low-privileged execution is common.
4. VPN, security, storage, and network appliances that depend on embedded Linux kernels.
5. Administrative jump hosts and shared engineering systems.

The key operational trap is assuming package installation equals remediation. Kernel fixes often require a reboot, live-patch confirmation, node replacement, or appliance firmware update before the corrected code is active. Asset owners should compare the installed kernel, the running kernel, and vendor advisory status before closing the ticket.

Detection and response posture

CISA's KEV entry requires applicable mitigations and forensics triage under BOD 26-04 guidance. That is a reminder to look for signs of attempted exploitation, not only to install patches.

Useful checks include unusual local crash patterns, kernel oops messages, suspicious use of AF_ALG sockets by processes that normally should not touch kernel crypto APIs, unexpected privilege changes after application compromise, and anomalous activity from workloads that recently handled public input. If exploitation evidence appears, treat the finding as an incident response matter rather than a routine maintenance task.

Because AF_ALG may be legitimate in some environments, detection should be tuned around baseline behavior. A noisy generic rule can distract analysts; a focused review of sensitive hosts, compromised-adjacent systems, and rare AF_ALG use is more likely to produce useful evidence.

Patch planning for today

The fastest good response is not complicated:

1. Pull the vendor-specific affected-version list for each Linux distribution or appliance family.
2. Identify systems where the fixed kernel is installed but not active.
3. Prioritize reboots, live patches, or node rotations for high-risk hosts.
4. Apply compensating controls where a vendor fix is not yet available.
5. Keep an exception list with owners and expiry dates for systems that cannot move today.

Red Hat notes that scoring may differ by vendor packaging and product context, which is normal for Linux kernel issues. Do not let score variance create a debate that delays action. CISA's active-exploitation signal and due date are enough to justify fast remediation on exposed, shared, and business-critical Linux assets.

The broader lesson

CVE-2025-39964 is a good example of why exploit-informed vulnerability management has to combine external advisories with internal runtime truth. A scanner can say a package is present. A CMDB can say a host exists. Neither proves the corrected kernel is running or that a container platform has rotated every vulnerable node.

For today's deadline, the best answer is concrete evidence: affected assets identified, vendor guidance applied, running kernels verified, reboots completed where needed, and suspicious local activity reviewed. Anything less leaves a kernel-level exploit path sitting behind whatever initial access attackers already have.

References

1. CISA Known Exploited Vulnerabilities catalog - CVE-2025-39964
2. NVD - CVE-2025-39964
3. CVE-2025-39964
4. crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg