CVE-2025-39964: Linux Kernel AF_ALG Race Condition Added to CISA KEV — Detection and Remediation Guide

On September 18, 2026, CISA added CVE-2025-39964 to its Known Exploited Vulnerabilities (KEV) catalog, formally confirming what many of us in the IR community have been tracking: a race condition in the Linux kernel's AF_ALG (kernel crypto API socket interface) is being actively exploited in the wild.

The flaw allows concurrent writes to the same AF_ALG socket, causing data to become unpredictably interleaved and corrupting the socket's internal state. In practical terms, this is a kernel-level memory/state consistency bug — the class of vulnerability that skilled operators weaponize into privilege escalation primitives. When a local attacker or a compromised process can trigger inconsistent internal socket state, the downstream consequences frequently include use-after-free conditions, out-of-bounds writes, and ultimately kernel code execution or privilege escalation to root.

If you run Linux anywhere in your estate — servers, containers, cloud VMs, network appliances, embedded devices — this is your problem. CISA's binding operational directive language (BOD 26-04) applies to federal civilian agencies, but the KEV listing should be treated as an emergency patch priority for every organization.

Technical Analysis

Affected Component

CVE-2025-39964 resides in the Linux kernel's AF_ALG socket implementation (crypto/af_alg.c and related code paths). AF_ALG is the user-space interface to the kernel's cryptographic API — it allows processes to request encryption, hashing, and other cryptographic operations through a socket-based interface rather than implementing crypto in user space.

The interface is widely used by:

• OpenSSL and other TLS libraries configured for kernel crypto offload
• dm-crypt and LUKS-related tooling
• VPN software leveraging kernel crypto acceleration
• Containerized workloads where the host kernel exposes the interface
• Applications using AF_ALG directly via socket(AF_ALG, SOCK_SEQPACKET, 0) and bind() with algorithm names such as hash, skcipher, aead, or rng

How the Vulnerability Works (Defender's Perspective)

The bug is a Time-of-Check Time-of-Use (TOCTOU) style race condition in the AF_ALG socket's write path. When two or more threads (or processes sharing the socket file descriptor) issue concurrent write operations against the same AF_ALG socket, the kernel fails to properly serialize access. The result:

1. Data interleaving — cryptographic input buffers become unpredictably mixed between concurrent operations.
2. Internal state corruption — the socket's internal bookkeeping (operation context, buffer pointers, outstanding request state) becomes inconsistent.
3. Exploitable kernel state — inconsistent socket state is the classic launching point for use-after-free or type-confusion primitives. A local attacker with the ability to open and write to an AF_ALG socket can race threads to corrupt kernel memory in a controlled fashion.

Exploitation Requirements

• Local access required: The attacker needs the ability to execute code on the target host and open an AF_ALG socket. This is a local privilege escalation (LPE) vector, not a remote exploit on its own.
• However, this is precisely why it's dangerous in containerized and multi-tenant environments: an attacker who has achieved initial code execution inside a container (via a compromised web app, a poisoned dependency, or a supply-chain foothold) can use this bug to escape to the host kernel if the container runtime has not blocked AF_ALG via seccomp.
• Race condition exploitation typically requires multiple attempts, which means crash artifacts, kernel oops logs, and repeated syscall patterns are observable — defenders have detection surface here.

Exploitation Status

• CISA KEV: Confirmed active exploitation (added 2026-09-18)
• This is not theoretical. Treat as an active incident-risk item.
• Federal agencies are bound by CISA BOD 26-04 (Prioritizing Security Updates Based on Risk) and must also comply with CISA's Forensics Triage Requirements referenced in the KEV entry.

Detection & Response

Detecting a kernel race condition directly is difficult, but exploitation attempts leave strong, low-noise indicators. Focus on three observable behaviors: (1) processes opening AF_ALG sockets, (2) kernel crash/oops artifacts consistent with race-triggered corruption, and (3) the af_alg kernel module being loaded on hosts that have no business using kernel crypto offload.

In most enterprise environments, legitimate AF_ALG usage is rare and concentrated in specific crypto/VPN tooling. A web server process, shell, or unexpected binary opening an AF_ALG socket (socket family 38) is a high-fidelity hunting signal.

Sigma Rules

---
title: Suspicious Process Opening AF_ALG Kernel Crypto Socket
id: 3f8a1c92-5b6d-4e7a-9c21-8d4e5f6a7b8c
status: experimental
description: Detects non-standard processes invoking socket(AF_ALG) via auditd syscall logging. AF_ALG usage is rare in most environments; unexpected use may indicate exploitation of CVE-2025-39964, a race condition in the Linux kernel crypto API socket interface.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2025-39964
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/09/18
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  product: linux
  service: auditd
detection:
  selection:
    type: SYSCALL
    syscall: socket
    a0: 26  # AF_ALG socket family (38 decimal = 0x26; auditd may log hex or decimal — tune per pipeline)
  filter_known_crypto:
    exe:
      - '/usr/sbin/openvpn'
      - '/usr/sbin/ipsec'
      - '/usr/lib/systemd/systemd-cryptsetup'
  condition: selection and not filter_known_crypto
falsepositives:
  - VPN and disk-encryption tooling using kernel crypto offload
  - Java runtimes and OpenSSL configured with kernel crypto engines
level: high
---
title: Kernel Oops or BUG Message Indicating AF_ALG State Corruption
id: 8c2d4e61-7a9b-4f3c-b1d2-6e5f8a9c0d1e
status: experimental
description: Detects kernel oops, BUG, or general protection fault messages referencing AF_ALG code paths in kernel logs. Repeated crashes in crypto socket handling are consistent with failed or iterative exploitation attempts against the CVE-2025-39964 race condition.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2025-39964
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/09/18
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  product: linux
  service: kern
detection:
  selection_keywords:
    - 'af_alg'
    - 'alg_socket'
    - 'crypto/af_alg'
  selection_crash:
    Message|contains:
      - 'BUG'
      - 'Oops'
      - 'general protection fault'
      - 'use-after-free'
      - 'KASAN'
  condition: selection_crash and selection_keywords
falsepositives:
  - Kernel debugging or fuzzing activity in development environments
level: critical
---
title: AF_ALG Kernel Module Manually Loaded
title_note: Load of af_alg module on hosts where kernel crypto socket interface is not baseline-approved
id: 5e7f9a12-3c4d-4e5f-a6b7-9c0d1e2f3a4b
status: experimental
description: Detects manual loading of the af_alg kernel module via modprobe or insmod. Where the module has been blocklisted as a CVE-2025-39964 mitigation, any load attempt is a strong indicator of tampering or pre-exploitation setup.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2025-39964
  - https://attack.mitre.org/techniques/T1547.006/
author: Security Arsenal
date: 2026/09/18
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.persistence
  - attack.t1547.006
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    Image|endswith:
      - '/modprobe'
      - '/insmod'
      - '/kmod'
    CommandLine|contains:
      - 'af_alg'
      - 'algif_hash'
      - 'algif_skcipher'
      - 'algif_aead'
      - 'algif_rng'
  condition: selection
falsepositives:
  - System provisioning scripts that legitimately enable kernel crypto
  - Administrator re-enabling the module during maintenance windows
level: medium

Microsoft Sentinel / Defender KQL

Linux auditd and syslog data ingested into Sentinel gives you solid hunting coverage for both socket creation and kernel crash artifacts:

// Hunt 1: Processes creating AF_ALG sockets (socket family 38 decimal / 0x26 hex)
// Requires auditd SYSCALL records ingested via the Linux AuditD or Syslog connector
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has "socket" and (SyslogMessage has "af_alg" or SyslogMessage has "a0=26" or SyslogMessage has "a0=00000026")
| extend Host = Computer, User = coalesce(Extract(@"auid=([0-9]+)", 1, SyslogMessage), "unknown")
| extend Process = Extract(@"exe=\"?([^\"\s]+)", 1, SyslogMessage)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Attempts = count()
  by Host, Process, User
| order by Attempts desc
;

// Hunt 2: Kernel crash artifacts referencing AF_ALG code paths
Syslog
| where TimeGenerated > ago(7d)
| where Facility =~ "kern"
| where SyslogMessage has_any ("BUG", "Oops", "general protection fault", "use-after-free", "KASAN")
| where SyslogMessage has_any ("af_alg", "alg_socket", "algif_", "crypto/af_alg")
| project TimeGenerated, Computer, SeverityLevel, SyslogMessage
| order by TimeGenerated desc
;

// Hunt 3: af_alg module load events (modprobe/insmod) — flag on hosts with the mitigation applied
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("modprobe", "insmod")
| where SyslogMessage has_any ("af_alg", "algif_hash", "algif_skcipher", "algif_aead", "algif_rng")
| project TimeGenerated, Computer, SyslogMessage
| order by TimeGenerated desc

Velociraptor VQL

For DFIR teams performing triage — also a CISA BOD 26-04 Forensics Triage Requirements consideration — this artifact checks whether af_alg is loaded, whether it's blocklisted, and enumerates processes holding AF_ALG sockets open:

-- Triage artifact: CVE-2025-39964 AF_ALG exposure assessment
-- 1. Check if af_alg module is currently loaded
SELECT Name, Size, UsedBy
FROM parse_file(filename='/proc/modules', accessor='data', record_regex='(?P<Name>\\S+)\\s+(?P<Size>\\d+)\\s+\\d+\\s+(?P<UsedBy>.*)')
WHERE Name =~ 'af_alg|algif_'

-- 2. Enumerate processes with open AF_ALG sockets (socket family 38)
SELECT Pid, Name, CommandLine, Username, CreateTime,
       parse_string_array(array=FD).String AS OpenFDs
FROM pslist()
WHERE Name AND CommandLine
  AND read_file(filename=format(format='/proc/%v/net/alg', args=Pid), accessor='data') =~ 'alg'

-- 3. Verify blocklist mitigation presence on disk
SELECT FullPath, Mtime, Size,
       read_file(filename=FullPath) AS Contents
FROM glob(globs='/etc/modprobe.d/*.conf')
WHERE Contents =~ 'af_alg|algif_'

Note: artifact #2 requires a Velociraptor build with /proc access on Linux clients; where that's not available in your deployment, collect /proc/net/alg and per-process fd/ symlink data via a scripted collection instead.

Remediation & Verification Script

The following Bash script checks exposure, applies the module blocklist mitigation (the primary workaround where patching is not immediately possible), and verifies kernel patch level. Run it across your fleet via your configuration management tooling:

#!/bin/bash
# CVE-2025-39964 - AF_ALG race condition mitigation & verification
# Run as root. Test in staging before broad deployment.

set -euo pipefail

echo "=== CVE-2025-39964 AF_ALG Exposure Check ==="
echo "Kernel: $(uname -r)"

# 1. Check if af_alg is currently loaded
if lsmod | grep -qE '^(af_alg|algif_)'; then
    echo "[!] af_alg module family is LOADED — host is exposed to CVE-2025-39964"
    lsmod | grep -E '^(af_alg|algif_)'
else
    echo "[+] af_alg not currently loaded"
fi

# 2. Check for processes actively using AF_ALG sockets
if [ -r /proc/net/alg ]; then
    SOCKCOUNT=$(wc -l < /proc/net/alg)
    if [ "$SOCKCOUNT" -gt 1 ]; then
        echo "[!] Active AF_ALG sockets detected ($((SOCKCOUNT-1)) entries). Review before blocklisting:"
        head -20 /proc/net/alg
    fi
fi

# 3. Apply blocklist mitigation (skip if VPN/crypto tooling depends on it)
read -r -p "Apply af_alg blocklist mitigation? [y/N] " REPLY
if [[ "$REPLY" =~ ^[Yy]$ ]]; then
    cat > /etc/modprobe.d/block-cve-2025-39964.conf <<'EOF'
# CVE-2025-39964 mitigation - disable AF_ALG kernel crypto socket interface
blacklist af_alg
blacklist algif_hash
blacklist algif_skcipher
blacklist algif_aead
blacklist algif_rng
install af_alg /bin/false
install algif_hash /bin/false
install algif_skcipher /bin/false
install algif_aead /bin/false
install algif_rng /bin/false
EOF
    # Unload now if possible (will fail if in use — that's a signal to investigate)
    for mod in algif_rng algif_aead algif_skcipher algif_hash af_alg; do
        modprobe -r "$mod" 2>/dev/null && echo "[+] Unloaded $mod" || echo "[-] Could not unload $mod (in use or not loaded)"
    done
    echo "[+] Blocklist written to /etc/modprobe.d/block-cve-2025-39964.conf"
    echo "[!] Reboot recommended to guarantee the module stays unloaded"
fi

# 4. Container hardening note: ensure seccomp profiles block the AF_ALG socket family
# Docker/containerd default seccomp already blocks AF_ALG on modern releases — verify with:
#   grep -i 'af_alg\|38' /path/to/seccomp-profile.json

echo "=== Done. Confirm kernel update via your distro advisory (see article) ==="

Remediation

1. Patch the Kernel — This Is the Only Complete Fix

The blocklist mitigation removes the attack surface, but the definitive fix is a patched kernel. As of the KEV listing, the fix has landed in upstream stable kernel branches. Apply your distribution's updated kernel packages immediately:

• RHEL / CentOS Stream / Alma / Rocky: dnf update kernel and reboot — check Red Hat's CVE page for the exact fixed kernel package version for your release.
• Ubuntu: apt update && apt install linux-image-generic (or your HWE/metapackage variant), then reboot. Confirm against the Ubuntu Security Notices entry for CVE-2025-39964.
• Debian: apt update && apt full-upgrade and reboot.
• SUSE/openSUSE: zypper patch with the relevant kernel update.
• Cloud images (AWS/Azure/GCP): Refresh to the latest AMI/image build and cycle instances — remember that the running kernel only changes on reboot or live-patch. If you use kpatch/kGraft/livepatch services, verify a live patch exists for this CVE before assuming coverage.
• Container hosts and Kubernetes nodes: Node-level patching is mandatory — containers share the host kernel. Drain, patch, reboot, uncordon.
• Appliances and embedded Linux: Engage the vendor. Many network appliances, hypervisors, and IoT/OT devices ship kernels with AF_ALG enabled and cannot be self-patched — pressure vendors for timelines and document compensating controls.

2. Apply the Workaround Where Patching Must Wait

If a reboot window or vendor fix is days away, the blocklist mitigation in the script above eliminates the local attack surface. Caveats:

• Verify no production dependency first: OpenSSL with kernel crypto engine, strongSwan/OpenVPN with kernel offload, and dm-crypt tooling can use AF_ALG. Test in staging.
• The install <module> /bin/false lines prevent explicit loads even by root — this also creates a detection tripwire (see Sigma rule 3).
• A reboot is the only way to guarantee a currently-loaded module is gone if it's in use.

3. Container and Seccomp Hardening

Because CVE-2025-39964 is a local escalation primitive, container breakout is the highest-risk scenario:

• Confirm your container runtime's seccomp profile blocks the AF_ALG socket family (modern Docker/containerd defaults do; custom or permissive profiles may not).
• Drop CAP_SYS_MODULE and run with no-new-privileges everywhere possible.
• Audit any workload running --privileged — those can load kernel modules and negate the blocklist.

4. Compliance Deadlines

• CISA KEV due date: Per BOD 26-04, federal civilian executive branch agencies must remediate per the directive's risk-based timeline and satisfy CISA's Forensics Triage Requirements — meaning preserve evidence and perform triage before wiping/reimaging potentially affected systems.
• Private sector: No mandate, but treat the KEV listing as your SLA trigger. Our standing recommendation: KEV-listed kernel LPEs on internet-adjacent or multi-tenant hosts get a 72-hour patch-or-mitigate window.

5. Post-Remediation Forensics

Given confirmed in-the-wild exploitation, don't assume patching closes the book:

• Hunt backward across kernel logs and auditd data for the indicators in the queries above (race-condition exploitation is noisy — crash loops and repeated socket churn are common).
• On hosts with kernel oops artifacts referencing af_alg, assume possible compromise and perform root-level triage: check for unexpected setuid binaries, new kernel modules, and persistence in systemd units or cron.
• Where evidence of exploitation exists, treat it as an incident, not a patch ticket.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub