AF_ALG concurrent-write race: local bug in the kernel crypto interface (af_alg)
CVE-2025-39964 CVSS 7.8 High (kernel CNA) / 5.5 Medium (NVD) published October 13, 2025 Ubuntu priority: High Red Hat CVSS 7.3 On CISA's Known Exploited list since 2026-09-18
Two writes to the same AF_ALG socket at the same time can interleave their data and leave the socket's internal state inconsistent. A low-privileged local user can use that to corrupt crypto state or crash the machine.
Versions and advisories below were checked on 2026-10-01 against the Ubuntu CVE tracker, Red Hat's CVE data and NVD (read through a summarising tool, so re-check a number against the vendor page before you rely on it). A kernel NEWER than the one listed also contains the fix.
Defensive notes only: no exploit code here. Only run the mitigation on machines you own or administer.
IMPORTANT: NVD's CISA fields list this CVE in CISA's Known Exploited Vulnerabilities catalog (added 2026-09-18, due date 2026-09-21). Treat it as "being used in the wild": patch.
Why the scores disagree
The Linux kernel CNA scores it 7.8 (high impact on confidentiality, integrity and availability). NVD's own analyst scored it 5.5 (only availability, meaning a crash). Red Hat scored it 7.3. Ubuntu's CVSS shows 5.5 but its priority is High. Everyone agrees it is a LOCAL bug (an attacker needs to run code on the machine). The spread in the numbers is about how much damage the race can do beyond a crash.
What it is, in plain English
Linux lets ordinary programs ask the kernel to do encryption and hashing for them through a special kind of socket called AF_ALG. If two threads write to the SAME socket at once, the kernel could mix up their data and mis-track its own state, because nothing enforced that only one writer at a time owns the socket.
The upstream fix (commit "crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg") adds a new field, ctx->write, that records exclusive ownership of the socket for writing, so a second writer is refused.
This is the same kernel interface family as Copy Fail (CVE-2026-31431, algif_aead), but a DIFFERENT bug in the shared core of AF_ALG (af_alg_sendmsg). Blocking one does not necessarily cover the other: patch the kernel.
Who is affected
Ubuntu: 14.04 is listed as vulnerable (no fix); 16.04, 18.04, 20.04, 22.04, 24.04 and 25.04 have fixes; 25.10 and 26.04 are NOT affected.
Red Hat family: RHEL 7 (extended life), 8, 9 and 10 (and their EUS/E4S streams) have fixes. RHEL 6 is not affected. The real-time kernel (kernel-rt) on RHEL 9 is still marked affected.
Others: Debian, SUSE, Amazon Linux and rebuilds published their own advisories.
Lower risk: machines where nobody untrusted can run code. Still patch them.
The kernel pieces involved
Piece What it is Where it lives
af_alg the core of the AF_ALG user-space crypto socket interface Check your kernel: loadable module (=m) or built in (=y), see the config check below (Red Hat builds at least algif_aead in)
algif_* the individual interfaces (hash, skcipher, aead, rng) Modules built on top of af_alg
What breaks if you block it: any program that uses the kernel crypto API through AF_ALG sockets loses that path (some wireless, disk-encryption and benchmarking tools can use it, and so can OpenSSL's "afalg" engine if configured). Many programs fall back to their own user-space crypto, but not all do. Test first.
Check your exposure first
uname -r # the kernel you are running RIGHT NOW (compare with the tables below)
lsmod | grep -E '^(af_alg|algif_)' # which AF_ALG modules are loaded at this moment? (nothing printed = none loaded, or built in)
grep -E 'CONFIG_CRYPTO_USER_API(_HASH|_SKCIPHER|_AEAD|_RNG)?=' /boot/config-$(uname -r)
# =m: a module (can be blocked with modprobe) =y: built in (cannot)
cat /proc/cmdline # look for initcall_blacklist=... if you already applied a Red Hat boot argument
ls /etc/modprobe.d/ | grep -i alg # any block file already installed
Careful: "nothing loaded right now" does not mean "safe": a program can load these modules on demand.
Mitigation
Red Hat's CVE page says plainly that for this CVE a mitigation "is either not available or the currently available options do not meet" its criteria. Ubuntu publishes none beyond the patch either. There is NO reliable workaround: patch the kernel.
If you cannot patch yet and nothing on the machine needs the kernel crypto API from user space, you can optionally stop AF_ALG from being usable. This is a stopgap that you test yourself, not a vendor-published fix for this CVE:
Ubuntu (AF_ALG normally a module there: the config check above confirms it on your kernel):
1. Block the modules from loading:
printf 'install af_alg /bin/false\ninstall algif_hash /bin/false\ninstall algif_skcipher /bin/false\ninstall algif_aead /bin/false\ninstall algif_rng /bin/false\n' | sudo tee /etc/modprobe.d/manual-disable-af_alg.conf
2. Unload them if loaded (errors hidden; an in-use module refuses):
sudo rmmod algif_rng algif_aead algif_skcipher algif_hash af_alg 2>/dev/null
3. Verify:
modprobe -n -v af_alg # should print: install /bin/false
Undo it later, after you have installed the patched kernel and rebooted into it:
sudo rm /etc/modprobe.d/manual-disable-af_alg.conf
sudo reboot
Red Hat / RHEL: modprobe cannot block built-in code. The boot argument in Red Hat's Copy Fail bulletin (RHSB-2026-002), initcall_blacklist=af_alg_init, disables the whole AF_ALG interface, so it should also take away the attack surface for this bug. Red Hat does NOT list it as a mitigation for CVE-2025-39964, so treat this as unverified and test it first:
sudo grubby --update-kernel=ALL --args="initcall_blacklist=af_alg_init"
sudo reboot
cat /proc/cmdline # should contain initcall_blacklist=af_alg_init
Undo it later: sudo grubby --update-kernel=ALL --remove-args="initcall_blacklist=af_alg_init" then reboot.
If you already added a different initcall_blacklist argument (for example the narrower Copy Fail one), put several functions in ONE argument separated by commas rather than repeating the argument.
Containers: AF_ALG sockets can usually be denied with a seccomp profile (the default container profiles may or may not allow them: check yours). The host kernel is what matters, so a host patch fixes every container on it.
The real fix: install the patched kernel and REBOOT
Ubuntu:
sudo apt update && sudo apt upgrade
sudo reboot
Red Hat / RHEL:
sudo dnf upgrade --refresh 'kernel*'
sudo reboot
A kernel update does nothing until you boot into it. Run uname -r afterwards and compare with the tables below.
Already installed the Copy Fail kernels from the Copy Fail guide? For the main Ubuntu kernel lines (18.04, 20.04, 22.04 and 24.04) those are newer than the ones below, so you are covered here too.
Patched kernels: Ubuntu (first fixed versions; anything newer is also fixed)
Release Kernel line Fixed in
24.04 LTS Noble Linux 6.8 6.8.0-90.91
22.04 LTS Jammy Linux 5.15 5.15.0-164.174
20.04 LTS Focal Linux 5.4 5.4.0-224.244
18.04 LTS Bionic Linux 4.15 4.15.0-245.257
16.04 LTS Xenial Linux 4.4 4.4.0-276.310
25.04 Plucky linux (6.14) 6.14.0-37.37 (25.04 is end-of-life: move to a supported release)
25.10 Questing and 26.04 Resolute: not affected
14.04 Trusty vulnerable, no fix listed
Cloud kernel examples (first fixed): 24.04 linux-aws 6.8.0-1044.46 linux-azure 6.8.0-1044.50 linux-oracle 6.8.0-1041.42 25.04 linux-gcp 6.14.0-1021.22 linux-raspi 6.14.0-1019.19
Other cloud and special kernels have their own numbers: look them up on https://ubuntu.com/security/CVE-2025-39964.
18.04 and earlier are past standard support: their fixes come through Ubuntu Pro (ESM).
Patched kernels: Red Hat Enterprise Linux (kernel package; "or newer" applies)
RHEL 10 (10.2) 6.12.0-211.58.1.el10_2 (RHSA-2026:70498, Sept 23 2026)
RHEL 10.0 EUS 6.12.0-55.106.1.el10_0 (RHSA-2026:71326, Sept 24 2026)
RHEL 9 (9.8) 5.14.0-687.50.1.el9_8 (RHSA-2026:70459, Sept 23 2026)
RHEL 9.6 EUS 5.14.0-570.143.1.el9_6 (RHSA-2026:71327, Sept 24 2026)
RHEL 9.4 E4S 5.14.0-427.152.1.el9_4 (RHSA-2026:71569, Sept 24 2026)
RHEL 9.2 E4S 5.14.0-284.194.1.el9_2 (RHSA-2026:71601, Sept 24 2026)
RHEL 8 (8.10) 4.18.0-553.166.1.el8_10 (RHSA-2026:70402, Sept 22 2026)
RHEL 8.8 TUS/E4S 4.18.0-477.170.1.el8_8 (RHSA-2026:71594, Sept 24 2026)
RHEL 8.6 AUS 4.18.0-372.218.1.el8_6 (RHSA-2026:71592, Sept 24 2026)
RHEL 8.4 AUS 4.18.0-305.209.1.el8_4 (RHSA-2026:71565, Sept 24 2026)
RHEL 7 ELS 3.10.0-1160.164.1.el7 (RHSA-2026:71687, Sept 24 2026)
RHEL 6: not affected.
Real-time kernels: RHEL 9 kernel-rt was still marked "Affected" when checked; RHEL 8 kernel-rt 4.18.0-553.166.1.rt7.507.el8_10 and RHEL 7 kernel-rt 3.10.0-1160.164.1.rt56.1316.el7 are fixed. NVIDIA for RHEL 10: 6.12.0-259.27.el10nv.
Rebuilds (AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux) use their own package numbers: follow their advisories, not this table.
Careful: Red Hat's fixed kernels for this CVE are from September 2026, so a RHEL machine that has only the Copy Fail kernels from May 2026 is NOT yet fixed. Check with the commands below.
Is my kernel patched?
Ubuntu:
uname -r # compare with the Ubuntu table above
apt changelog linux-image-$(uname -r) | grep CVE-2025-39964 # the changelog should mention the CVE
pro fix CVE-2025-39964 --dry-run # Ubuntu Pro client: says whether this machine is fixed
Red Hat / RHEL:
uname -r # compare with the RHEL table above
rpm -q --changelog kernel-$(uname -r) | grep CVE-2025-39964 # the changelog should mention the CVE
sudo dnf updateinfo list --cve CVE-2025-39964 # which advisory fixes it and whether it is installed
sudo needs-restarting -r # says whether a reboot is still needed
Careful: rpm -q kernel and dpkg -l 'linux-image*' list INSTALLED kernels, including old ones you are not running. Only uname -r tells you what is actually running.
Common problems
The block file exists but a module still loads: check modprobe -n -v af_alg (it must print install /bin/false) and that the file ends in .conf and sits in /etc/modprobe.d/.
Something broke after blocking AF_ALG (Wi-Fi, an encrypted volume, a tool that used kernel crypto): that is the side effect. Undo the block and patch instead.
"install ... /bin/false" did nothing on RHEL: expected, the code is built in. Use the boot argument or patch.
I updated a RHEL box in May and it is still listed as affected: the fixed kernels for this CVE came in September 2026. Update again.
I updated but uname -r shows the old kernel: you have not rebooted yet.
Tips
Patch and reboot beats blocking every time. Treat any block as a temporary bandage and remove it afterwards.
Prioritise by who can run code: shared servers, container hosts, Kubernetes nodes, CI runners, jump boxes and anything with many SSH users come first.
AF_ALG is also where Copy Fail lives. If a machine has no reason to use kernel crypto from user space, denying the interface by policy is a sensible hardening step even after you patch: test it, document it, and keep the date in a comment.
The CVSS numbers (5.5, 7.3, 7.8) differ because they guess at the damage. The CISA entry is not a guess: someone has actually used it.
Put the date and reason in a comment inside any block file you create. "Why does this box not do hardware crypto?" is a bad mystery at 2 a.m.
Two threads writing to the same socket at once is the kernel equivalent of two people editing the same spreadsheet cell. Only one of them leaves happy.
Sources (checked 2026-10-01)
Ubuntu CVE tracker: https://ubuntu.com/security/CVE-2025-39964
Red Hat CVE page: https://access.redhat.com/security/cve/cve-2025-39964
Red Hat CVE data feed: https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-39964.json
NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2025-39964
Red Hat Copy Fail bulletin (boot argument): https://access.redhat.com/security/vulnerabilities/RHSB-2026-002