CVE-2026-31431 — Copy Fail Tracking

This tracker is no longer updated as all the tracked distros have released fixes.

Summary

An unprivileged local user can perform a controlled 4-byte write into the page cache of any readable file via the AF_ALG socket interface’s algif_aead module. Because the page cache is host-wide, this is also a container escape primitive on shared-kernel multi-tenant hosts. The modification is in-memory only — the on-disk file is unchanged, so standard file integrity tooling (checksums, inotify, auditd file watches) will not detect it.

Vulnerable commit range

The full fix is a series of 3 commits, not just the algif_aead revert alone. Distro backports must include all three commits to be fully effective.

Every kernel between those two commits (carrying 72548b093ee3 but not a664bf3d603d or its stable-branch equivalent) is vulnerable.

Upstream fixed versions

Distribution status

Debian

Main reference: Debian Security Tracker

A standard upgrade and reboot is sufficient on every supported release:

apt update && apt full-upgrade

reboot

Proxmox Virtual Environment

Main references: Proxmox PVE security advisories · ProxmoxSecurityAdvisory posts

Proxmox ships its own pve-kernel packages, built independently from Debian’s kernel packages, so the Debian fix timeline above does not apply here. PSA-2026-00018-1 covers both PVE 9 and PVE 8 across all three kernel series (6.17, 6.14, 6.8). Note that pve-container must also be updated alongside the kernel — the PSA lists it as a required fix package (6.1.5+ for PVE 9, 5.3.5+ for PVE 8).

PVE 9 fixed in the default 6.17 kernel. The 7.0 kernel series (proxmox-kernel-7.0.0-*-pve) is listed as unaffected.

PVE 8 uses the 6.14 or 6.8 kernel series. Fixed versions are proxmox-kernel-6.14.11-7-pve (and 6.14.11-7-bpo12-pve for the bookworm backport variant) and proxmox-kernel-6.8.12-22-pve.

A standard upgrade and reboot is sufficient on both versions:

apt update && apt full-upgrade

reboot

On PVE kernels algif_aead is a loadable module (not built-in as on Rocky/RHEL), so Option A also works as an interim workaround on unpatched nodes.

NixOS

Main reference: NixOS security tracker

NixOS unstable is fixed: The default kernel for the 26.05 (unstable) cycle has been updated from 6.12 to 6.18. Any nixos-unstable system updated since 2026-04-11 is running ≥ 6.18.22 and is not vulnerable.

NixOS 25.11 — the situation depends on which kernel package is installed:

• Default (linux_6_12): Fixed. linux_6_12: 6.12.84 -> 6.12.85 was cherry-picked into release-25.11 at 10:03 UTC on 2026-04-30 (commit 248336e3, by zowoq). The fix completed Hydra testing and the full nixos-25.11 channel advanced past 248336e3 by 2026-05-04 — the channel pointer is now 26ef669c, confirmed 70 commits ahead of 248336e3 with behind_by=0. Run nixos-rebuild switch --upgrade to get the fix.

• Opt-in (linux_6_18): Fixed. linux_6_18: 6.18.21 -> 6.18.22 was cherry-picked into the 25.11 branch at 12:54:54 UTC on 2026-04-11 (commit b6dd55149b7c, 2 seconds after the unstable commit). Users who opt in to the 6.18 kernel on 25.11 are protected:

In configuration.nix (no longer required now that linux_6_12 6.12.85 is in nixos-25.11):

boot.kernelPackages = pkgs.linuxPackages_6_18;

Note also that 6.19 was EOL’d and removed from the 25.11 branch on 2026-04-23 (commit 8bb44436).

Rocky Linux

Main references: Rocky Linux errata · Red Hat CVE page · Rocky Linux forum thread

Red Hat shipped RHSA-2026:13566 (RHEL 10) and RHSA-2026:13565 (RHEL 9) on 2026-05-04, and RHSA-2026:13577 (RHEL 8 kernel) and RHSA-2026:13578 (RHEL 8 kernel-rt) on 2026-05-05, covering kernel and kernel-rt packages across all three releases.

Rocky Linux published RLSA-2026:13566 (Rocky 10), RLSA-2026:13565 (Rocky 9), and RLSA-2026:13577 (Rocky 8) on 2026-05-06, each explicitly listing CVE-2026-31431. Apply via dnf update kernel (Rocky 10/9) or yum update kernel (Rocky 8) and reboot.

🚨 Rocky/RHEL module workaround caveat: On all current Rocky/RHEL kernels (8, 9, 10), algif_aead is compiled directly into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y), so rmmod algif_aead and modprobe.d blacklist entries will silently have no effect. You will see no error, but the module remains active. Use the kernel boot parameter workaround (Option B below) instead.

Amazon Linux

Main references: Amazon Linux Security Center · AL2023 · AL2

Amazon Linux has updated their severity rating from Medium (CVSS 5.5) to Important (CVSS 7.8), now matching the NVD/CISA scoring.

Amazon Linux 2023

All three AL2023 kernel variants received fixes on 2026-05-05. The advisories confirm the core fix (“crypto: algif_aead - Revert to operating out-of-place”). Apply via dnf update kernel (or kernel6.12/kernel6.18 as appropriate) and reboot.

Amazon Linux 2

All four AL2 kernel variants received fixes on 2026-05-05. Apply via yum update kernel and reboot. If you are on a 5.x extras kernel, ensure you are subscribed to the appropriate extras advisory stream.

Detection

Check whether the module is loaded or built in

If this returns output, algif_aead is loaded as a module:

lsmod | grep algif_aead

If the above is empty, check for a built-in (common on RHEL/Rocky 8+):

grep algif_aead /lib/modules/$(uname -r)/modules.builtin

Or check the kernel config directly:

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

Interpret the output:

• =y → built-in, cannot be unloaded — use Option B
• =m → loadable module — use Option A
• no output → AF_ALG AEAD interface unavailable, not vulnerable

Fallback if /boot/config-* is unreadable and CONFIG_IKCONFIG_PROC=y:

zgrep CONFIG_CRYPTO_USER_API_AEAD /proc/config.gz

Non-destructive detector (from the public PoC)

Requires Python 3.10+ for os.splice. On Rocky/RHEL 9 (default Python 3.9), use the updated PoC PR #66 from the theori-io repo which backports splice support to older Python.

python3 test_cve_2026_31431.py

Exit codes:

• 0 = not vulnerable
• 2 = vulnerable
• 1 = test error (Python < 3.10 without the backport patch)

Runtime detection (Falco/Sysdig rule)

Detect exploitation attempts without patching by alerting on any unprivileged process opening an AF_ALG SOCK_SEQPACKET socket outside known crypto tools (cryptsetup, veritysetup, kcapi-*, etc.). See the Sysdig blog for a ready-made Falco rule.

Workaround

What this does NOT break: dm-crypt/LUKS, kTLS, IPsec/XFRM, SSH, OpenSSL/GnuTLS/NSS default builds, kernel keyring. These all use the in-kernel crypto API directly and do not go through AF_ALG.

What may break: Applications explicitly configured to use the afalg OpenSSL engine, or custom software that binds aead/skcipher/hash sockets directly. Assess with lsof | grep AF_ALG before applying.

⚠️ Read the platform-specific notes before applying any workaround. On all current Rocky/RHEL kernels (8, 9, 10), the standard modprobe approach silently does nothing. Applying it gives a false sense of protection.

Option A — modprobe blacklist (Debian, AL2023, AL2)

Works only when algif_aead is a loadable module (verify with lsmod first):

Block the module and prevent it loading on reboot:

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf

Attempt to unload if currently loaded (may fail if in use; reboot if so):

sudo rmmod algif_aead 2>/dev/null || echo "Module not loaded or built-in — reboot may be required"

Verify:

lsmod | grep algif_aead && echo "STILL LOADED" || echo "Not loaded"

Option B — kernel boot parameter (Rocky/RHEL 8+, any distro with built-in module)

When algif_aead is compiled in and cannot be unloaded, prevent it from registering at boot via the initcall_blacklist kernel parameter. This requires a reboot:

On systems using BLS config (Rocky/RHEL 8+, Fedora, AL2023), add the boot parameter:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

Reboot:

sudo reboot

After reboot, verify the parameter is active:

grep -o 'initcall_blacklist=algif_aead_init' /proc/cmdline \
  && echo "Mitigation active" || echo "NOT ACTIVE — check grubby output"

Risk notes

• Container hosts: The host-wide page cache means a container breakout is possible on shared-kernel deployments (Docker, Kubernetes without microVM or gVisor isolation). Patch or apply Option B before running untrusted workloads.
• CI/CD runners: Self-hosted GitHub Actions, GitLab Runners, and Jenkins agents executing untrusted PR code are directly in scope.
• Forensics: The exploit modifies only the in-memory page cache. The on-disk file is untouched. inotify, auditd file watches, and on-disk checksums will all report clean. Memory forensics or runtime detection (Falco, eBPF) is required.
• Embedded / appliance kernels: May lag significantly behind distro kernel updates. Audit separately.

Note: The exploit does not modify files on disk. The in-place AEAD operation bypasses set_page_dirty(), so corrupted pages are never marked dirty and writeback never flushes them to storage. The in-memory corruption is therefore transient: dropping the pagecache is sufficient to clear it, and a reboot achieves the same effect.

echo 1 > /proc/sys/vm/drop_caches

References