CVE-2025-39964 — Linux af_alg concurrent-write race

Summary

How the race works

The kernel’s cryptographic user API, AF_ALG, lets a user-space process drive an in-kernel cipher over a socket: socket(AF_ALG, …), bind() to an algorithm, sendmsg() to feed plaintext or ciphertext, and recvmsg() to read the result. On the write side, af_alg_sendmsg() appends the message’s pages to a per-socket transmit scatterlist (a chain of struct af_alg_tsgl blocks) that the read side later hands to the cipher.

Nothing serialised two sendmsg() calls on the same socket. A process running two threads that both call sendmsg() on one socket runs af_alg_sendmsg() twice at once against the same ctx. The two executions interleave their updates to the scatterlist and the running counters, so the list ends up describing something neither call intended. In particular a writer that parks in af_alg_wait_for_wmem() — which the attacker forces deterministically by sizing SO_SNDBUF and filling it, then draining it with its own recvmsg() — and then takes an error exit with the current entry count cur == 0 leaves the scatterlist underflowed: the next append reads a “previous” entry that does not exist and fabricates a scatterlist entry out of adjacent kernel list pointers.

That fabricated entry is what turns a race into memory corruption. On the read path af_alg_pull_tsgl() feeds it to skcipher_recvmsg() / aead_recvmsg(), so the cipher operates on an attacker-chosen kernel address and returns the result to userspace — a kernel memory disclosure primitive, not merely a pointer leak. On a subsequent write, memcpy_from_msg(page_address(sg_page(sg)) + sg->offset + sg->length, …) copies attacker-controlled bytes to an address derived from the bogus entry — a controlled kernel write. Dereferencing the bogus page_link, and the eventual put_page() on the fabricated page, also reliably oops the machine.

The public PoC chains these into root the way several recent kernel LPEs do: it grooms the 4 KB tsgl allocations, uses the out-of-bounds write to overwrite /proc/sys/kernel/core_pattern with a pointer to its own helper binary, and then crashes a process so the kernel executes that helper as root.

The fix, 1b34cbbf4f01, adds a ctx->write flag that grants one writer exclusive ownership of the socket for the duration of a sendmsg(); a second concurrent write returns -EBUSY instead of racing. Because AF_ALG is documented as single-stream, no legitimate caller issues concurrent writes, so the change breaks nothing.

ℹ️ Old bug, not a regression. The unserialised write path dates from v2.6.38 (2011), when the skcipher AF_ALG interface was first added. There is no in-support kernel old enough to predate it: every kernel from 2.6.38 up to a fixed release is in-window. A kernel is safe only by carrying the 1b34cbbf4f01 fix — not by being old.

Vulnerable commit range

The reachable lifetime runs from v2.6.38 through v6.16. No in-support kernel predates the flaw, so the only not-affected kernels are those that carry the fix.

Patch status

A row is Fixed only if its kernel carries the 1b34cbbf4f01 backport (or is a v6.17-or-later line that shipped with it); every AF_ALG-capable kernel from 2.6.38 on without it is in-window and Vulnerable. The first group is the upstream kernel; the rest are a focused set of x86-64 distributions, with per-distribution detail in the sections that follow. First fixed and Fixed since stay — until a row is fixed.

Linux kernel

The fix reached Linus in v6.17 — the commit landed on the mainline tree at v6.17-rc7 (tagged 2025-09-21), through the crypto tree. The stable backports followed almost at once: 6.1.154, 6.6.108, 6.12.49 and 6.16.9 on 2025-09-25, then 5.15.194 and 5.10.245 on 2025-10-02 — each the same fix by subject, confirmed present on its linux-*.y branch. Every branch created after v6.17 — 6.18, and the 7.0 / 7.1 / 7.2 / 7.3 lines — carries the fix from its first release, so those lines were never in-window.

6.16.y is fixed but end-of-life. The 6.16 line received the fix in 6.16.9 and reached end of life at 6.16.12 (2025-10-12); a 6.16 kernel at or above 6.16.9 carries the fix, and any host still on an earlier 6.16 build should move to a maintained line.

A companion commit, d0ca0df179c4 (crypto: af_alg - Fix incorrect boolean values in af_alg_ctx, tracked as CVE-2025-40022), repairs a 1-bit-bitfield regression introduced by the fix and ships in the same or the next stable release; a kernel carrying 1b34cbbf4f01 is fixed for this CVE whether or not it also has that follow-up.

To check a tree directly: a fixed af_alg_sendmsg() (in crypto/af_alg.c) tests and sets a ctx->write ownership flag and returns -EBUSY when a second writer is already active; an unfixed one has no such flag and no -EBUSY path.

Debian

Every Debian suite is fixed. sid and forky (testing) both crossed the fix when 6.16.9-1 migrated into testing, and have since advanced along the 7.x line. trixie (Debian 13) rides 6.12 and took the fix in a point-release kernel below the upstream 6.12.49 number; bookworm (Debian 12) rides 6.1 and was fixed by the DSA-6053-1 security update. The security tracker lists every suite as resolved.

bookworm also offers an opt-in newer kernel, the linux-6.12 source package in bookworm-security (trixie’s kernel rebuilt for bookworm). It was introduced well after the 6.12 branch’s fix, so every build of it carries the fix.

bullseye (Debian 11) reached the end of its LTS window on 2026-08-31, but received the fix before then: DLA-4404-1 fixed the default 5.10 kernel and DLA-4379-1 fixed the linux-6.1 opt-in (bookworm’s 6.1 kernel rebuilt for bullseye). Both rows are frozen at their final, fixed builds; no further updates will come, so a host still on bullseye should upgrade to bookworm or newer regardless.

Debian’s stock kernels build the AF_ALG interface as modules (CONFIG_CRYPTO_USER_API_SKCIPHER=m, _AEAD=m), autoloaded on first use, so an unpatched Debian kernel is reachable by any local user.

Proxmox VE

Proxmox ships its own Ubuntu-derived kernels, so Debian’s status does not carry over. PVE 9’s default is the 7.0 kernel (since PVE 9.2, 2026-05-21), which branched after v6.17 and carries the fix; the former 9.1 default, the opt-in 6.17 kernel, is fixed for the same reason. PVE 8’s default proxmox-kernel-6.8 is 6.8-based and in-window, but took the fix through Ubuntu’s 6.8.0-90.91 rebase, so its current build is fixed.

Both releases also still publish superseded kernel series that Proxmox stopped updating. PVE 8’s proxmox-kernel-6.5 and -6.2, and its bookworm-backports opt-in proxmox-kernel-6.11 (last built March 2025), predate the fix and will never receive it — a host booting any of them stays vulnerable until it switches to its release’s current default kernel. The 6.14 series that PVE 9.0 shipped and PVE 8 offers as a backport did receive the fix (via Ubuntu’s 6.14.0-37.37) before Proxmox stopped updating it, but it too is superseded; move up to the current default.

Proxmox hosts run the AF_ALG interface like any Debian-derived system, so an unpatched node is reachable by any local user or unprivileged container account.

NixOS

Every tracked ref’s default linuxPackages is linux_6_18, well past the fix, so every tracked ref is fixed — they differ only in when each first shipped a fixed kernel. The fix first reached nixpkgs in late September 2025 through the then-default 6.12 series (the 6.12.48 -> 6.12.49 bump on master), and every kernel series nixpkgs pins (linux_6_12 down to linux_5_10) has been at or above its branch’s first-fixed release since. The release-26.05 branch was cut in May 2026, already carrying a fixed default kernel.

Kernel updates land on nixpkgs master first, and each channel publishes them once its Hydra jobset passes, so a channel can sit a few days behind master. The -small channels (nixos-unstable-small, nixos-26.05-small) are gated on a reduced jobset and pick up kernel updates fastest. The master and release-26.05 rows are the git branches the fix lands on directly; they are development branches, not deployment targets.

Flake inputs map onto these directly. github:NixOS/nixpkgs/nixos-unstable tracks the nixos-unstable channel, and a bare github:NixOS/nixpkgs follows master. A bare nixpkgs registry input resolves to nixpkgs-unstable, a separate channel aimed at non-NixOS Nix users, which is not gated on the NixOS tests and can hold a different kernel from nixos-unstable.

Rocky Linux / RHEL family

RHEL-family kernels are long-lived forks; all three in-support lines — EL10 (6.12-based), EL9 (5.14-based), EL8 (4.18-based) — postdate the v2.6.38 introduction and build the AF_ALG interface, so all are in-window. Red Hat’s security data marks the kernel and kernel-rt packages Affected for RHEL 7, 8, 9, and 10 with no fixed release and no RHSA yet (RHEL 6 is Not affected), so every stream is vulnerable pending an advisory. Red Hat scores the flaw lower than the kernel CNA does — see Risk notes — which usually means the fix rides a regular batch kernel update rather than an out-of-cycle one. The kernel-rt real-time variant is listed Affected alongside the standard kernel and will be fixed by the same advisories. Rocky rebuilds RHEL’s kernels unchanged, so its fixes track Red Hat’s; AlmaLinux is typically the fastest rebuild and the leading indicator. Oracle Linux and CloudLinux track the RHEL determination.

Amazon Linux

All three AL2023 kernel streams are fixed: the default kernel (6.1 line) in ALAS2023-2025-1223 and the opt-in kernel6.12 in ALAS2023-2025-1254, while the opt-in kernel6.18 stream was introduced after v6.17 and carries the fix from its first build (no ALAS names this CVE for it). Amazon backports fixes into builds below the upstream threshold, so the advisory, not a version compare, is the verdict.

Amazon Linux 2 reached end of support on 2026-06-30, but was fixed before then: the kernel-5.10 and kernel-5.15 Extras streams took the fix in ALAS2KERNEL-5.10-2025-109 and ALAS2KERNEL-5.15-2025-093 (both 2025-10-27). AL2 is no longer tracked here; a host still on it should migrate to AL2023 for continued updates.

Detection

Is the running kernel in the affected window and missing the fix? Every AF_ALG-capable kernel from 2.6.38 on is in-window; compare the running kernel against the Patch status table’s First fixed column for its series (distro builds below that number can still carry a backport — the table’s Status is the verdict):

uname -r

Is the AF_ALG interface built? The bug needs the cryptographic user API. Almost every distribution enables it as modules (algif_skcipher, algif_aead), autoloaded when a process binds an AF_ALG socket:

grep CONFIG_CRYPTO_USER_API /boot/config-$(uname -r)

Can this user reach it right now? Any local user can open and bind an AF_ALG skcipher socket with no privilege; a success here means the path is reachable from an unprivileged shell:

python3 -c 'import socket; s=socket.socket(socket.AF_ALG,socket.SOCK_SEQPACKET,0); s.bind(("skcipher","cbc(aes)")); print("AF_ALG reachable")'

Are the modules already loaded? A loaded algif_* module means the interface is in use; an unloaded one is not protection, since binding an AF_ALG socket autoloads it:

lsmod | grep -E '^(af_alg|algif_)'

Mitigation

The real fix is a patched kernel (the 1b34cbbf4f01 backport). Unlike the container-escape class of kernel LPEs, this bug needs no capability and no namespace — every local user can reach AF_ALG directly — so disabling unprivileged user namespaces does nothing here. Until a fixed kernel is installed, the only lever is to take away the AF_ALG interface itself, on hosts that do not use the kernel crypto user API (most do not; userspace normally uses libcrypto/OpenSSL, not AF_ALG).

Block the AF_ALG modules

Where nothing on the host uses the kernel crypto user API, block the interface so the vulnerable code cannot load. This is Red Hat’s recommended mitigation. Test first — cryptsetup, some IPsec setups, and a few crypto-offload tools do use AF_ALG:

echo 'install algif_skcipher /bin/false' | sudo tee /etc/modprobe.d/cve-2025-39964.conf

Block the AEAD interface the same way, since it shares the vulnerable code:

echo 'install algif_aead /bin/false' | sudo tee -a /etc/modprobe.d/cve-2025-39964.conf

To cover every algorithm type at once, block the af_alg core module instead, which the algif_* modules depend on:

echo 'install af_alg /bin/false' | sudo tee /etc/modprobe.d/cve-2025-39964.conf

Risk notes

• It is in the CISA KEV catalog with a same-week deadline. CISA added CVE-2025-39964 on 2026-09-18 with a BOD 26-04 remediation date of 2026-09-21 and marked exploitation active; Red Hat likewise notes known public exploits. Federal civilian agencies must remediate on that timeline, and every in-window multi-user host should be treated as a live target.
• A working public exploit exists. The PoC is a self-tuning local-root exploit that overwrites core_pattern; it uses hardcoded kernel offsets, so adapting it to a given kernel is grooming work, not research.
• Reachable by any local user, with no capability. bind() and setkey() on an AF_ALG socket check no capability, and the modules autoload, so an ordinary shell account — including one inside an unprivileged container — can trigger the race. There is no namespace or capability mitigation; only a patched kernel or a blocked module closes it.
• The severity scores diverge. The kernel CNA and NVD’s CNA metric rate this 7.8 HIGH, treating the corruption as a full confidentiality/integrity/availability break (kernel memory read, controlled write, LPE). Red Hat rates it 5.5 Moderate, availability-only — a difference in how completely each judges the scatterlist underflow to be weaponisable, not a disagreement about the bug. The public PoC’s controlled write supports the higher reading.
• No kernel is too old to be affected. The bug dates from v2.6.38 (2011). Every in-support distribution kernel is in-window and unsafe until it carries the backport.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

References