On 29th April 2026 an advisory for CVE-2026-31431 was released alongside working proof of concept code. This is a privilege escalation vulnerability which is trivially exploitable and which affects all versions of Linux released since 2017. Shortly after this was published we sent an email to our HPCsec mailing list with the following advice. We have replicated this below. We will update this if new information, better advice, or corrections are necessary.
2026-04-30 – Email#1 – Initial Information
Overview
A local privilege escalation vulnerability in the Linux kernel was publicly disclosed today (CVE-2026-31431). It’s very relevant and significant to anyone running multi-user or multi-tenant Linux systems, so I wanted to flag it for you with some practical information.
What is it?
CVE-2026-31431 (“Copy Fail”) is a logic flaw in the kernel’s algif_aead module — the AF_ALG socket interface for Authenticated Encryption with Associated Data (AEAD). The bug was introduced in 2017 when an in-place operation optimisation was added (commit 72548b093ee3). Because the source and destination buffers come from different memory mappings, the in-place path was never actually beneficial — but it did create a 4-byte page-cache write primitive that can be used to modify setuid binaries in memory.
The result: a reliable, straight-line local privilege escalation. No race condition, no kernel-specific offsets. The public PoC is a 732-byte Python script.
CVSS: 7.8 (High)
Attack vector: Local – requires an unprivileged shell on the target system
Exploit maturity: Public PoC available on GitHub (theori-io/copy-fail-CVE-2026-31431)
HPC Relevant Context
This is a significant issue in multi-user HPC environments:
• Any unprivileged user with shell access on a login node, compute node, or build server can escalate to root.
• The AF_ALG kernel crypto API (specifically algif_aead) ships enabled in default kernel configs across all major distros.
• The exploit works without any special privileges, kernel debugging features, or pre-installed tools
• Shared compute environments with job schedulers (Slurm, PBS, etc.) where users run arbitrary code are directly in scope.
It’s worth noting that the disclosure page claims container escape capability, but this is being actively debated. Early testing by others suggests it does NOT escape user namespaces (e.g., rootless Podman). The primary concern for most of you will be the multi-user shared-kernel scenario, which is the bread and butter of HPC.
Also worth noting: the disclosure page references “RHEL 14.3” in its tested distributions table, which doesn’t exist — the kernel version string alongside it (6.12.0-124.45.1.el10_1) indicates this was actually RHEL 10. The vulnerability itself is real and verified, but treat some of the copy on the disclosure site with appropriate scepticism.
Affected Kernels
Any kernel built between 2017 and the fix (mainline commit a664bf3d603d). Upstream fixed versions: 6.18.22+ and 6.19.12+.
Check your distro’s tracker for backport status:
• Debian: https://security-tracker.debian.org/tracker/CVE-2026-31431
• Ubuntu: https://ubuntu.com/security/CVE-2026-31431
• RHEL: https://access.redhat.com/security/cve/CVE-2026-31431
• SUSE: https://www.suse.com/security/cve/CVE-2026-31431.html
Recommended Actions
1. Patch when your distro ships the fix. This is the ideal and recommended solution.
2. If you can’t patch immediately, disable the algif_aead module:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
This prevents the module from loading. For most HPC environments, this will break nothing – AF_ALG is a userspace front-door to kernel crypto that almost nothing actually uses. dm-crypt/LUKS, IPsec, kTLS, OpenSSL/GnuTLS default builds, and SSH all use the in-kernel crypto API directly and do NOT go through AF_ALG.
Things that COULD break: anything explicitly configured to use OpenSSL’s afalg engine, or applications that bind AF_ALG sockets directly. You can check with: lsof | grep AF_ALG
ss -xa | grep alg
That said, do double check, in your environment before you follow any of the above.
3. For environments running user-submitted containers or sandboxed workloads, consider blocking AF_ALG socket creation via seccomp as a defence-in-depth measure, regardless of patch status.
4. Check whether algif_aead is currently loaded on your systems: lsmod | grep algif_aead
If it’s not loaded (likely on most HPC nodes unless something specifically triggered it), the module blacklist alone provides effective mitigation.
5. If you want to validate your systems, the PoC is public. Test on a non-production node. The exploit modifies the page cache of a setuid binary – the change is not persistent across reboot, but the root shell it gives you is real.
Timeline
2026-03-23: Reported to Linux kernel security team
2026-03-25: Patches proposed and reviewed
2026-04-01: Patch committed to mainline
2026-04-22: CVE assigned
2026-04-29: Public disclosure (https://copy.fail)
References
• Disclosure page: https://copy.fail
• Technical write-up: https://xint.io/blog/copy-fail-linux-distributions
• PoC repo: https://github.com/theori-io/copy-fail-CVE-2026-31431
• Kernel patch: https://git.kernel.org/stable/c/a664bf3d603d
2026-04-30 – Email#2 – Updates and clarification
Follow-up to yesterday’s advisory on CVE-2026-31431 (Copy Fail). A few things have moved in the last 24 hours that are worth flagging.
Distro Patch Status
Debian, Ubuntu, and SUSE have now issued patches. Red Hat initially marked this as “fix deferred” / moderate severity, but has since reversed that position and will be patching promptly. Check your specific distro and release — not all branches have patches available yet. The distro tracker links from yesterday’s email remain the right place to monitor this.
For those who applied the algif_aead module blacklist yesterday as an interim measure: that remains effective and is still the recommended mitigation if you can’t patch yet. No urgency to remove it — even after patching, keeping AF_ALG locked down on multi-user systems is reasonable defence in depth.
RHEL Version Correction
Yesterday I noted that the copy.fail disclosure page listed “RHEL 14.3” in its tested distributions, which doesn’t exist. This has since been corrected to RHEL 10.1, which aligns with the kernel version string (6.12.0-124.45.1.el10_1) that was there from the start.
Container Escape: Stronger than Initially Reported
Yesterday I caveated the container escape claims as “actively debated”. The picture is now clearer and I’d upgrade the risk assessment.
Because the page cache is shared across all processes on a host — including across container boundaries — a process inside a container can corrupt the cached view of setuid binaries visible to the host and other containers. This means standard container runtimes on shared kernels (the normal case for HPC sites using Singularity/Apptainer) are affected.
The earlier HN report of it failing under rootless Podman is consistent with this – user namespaces add a layer that blocks it. But most HPC container deployments don’t use rootless runtimes or user namespaces, so don’t assume you’re covered.
Theori have indicated that a Part 2 covering full Kubernetes node compromise is forthcoming.
File Integrity Monitoring Won’t Catch This
This is worth highlighting for anyone relying on AIDE, Tripwire, OSSEC, or similar FIM tools: Copy Fail modifies the page cache only. The on-disk file is never touched. This means:
- FIM tools that check file hashes will not detect exploitation
- inotify-based monitoring will not trigger
- There is no forensic trace on disk after a reboot
Detection needs to focus on behavioural indicators – unexpected privilege escalation, anomalous setuid binary execution by unprivileged users, or unusual AF_ALG socket activity. If you have auditd deployed, consider adding rules for AF_ALG socket creation.
Affected Versions Clarified
The affected range is now more precisely documented: kernels from approximately v4.13 (2017, when commit 72548b093ee3 introduced the in-place AEAD optimisation) through to the fix. The upstream fix landed in 7.0-rc7 (commit a664bf3d603d) and has been backported to stable branches 6.18.22+ and 6.19.12+.
No Change
Everything else from yesterday’s email remains accurate: the technical description, CVSS 7.8 rating, mitigation steps, and references are all still current.
For convenience we’re also posting the contents of these emails on our HPCsec blog:
https://www.hpcsec.com/2026/04/30/advisory-cve-2026-31431-copy-fail-local-privilege-escalation-via-af_alg-algif_aead/