## https://sploitus.com/exploit?id=1D0D5548-E7C5-5972-AEA7-574E364142D9
# CVE-2026-31431 โ Copy Fail
> **Local Privilege Escalation** in the Linux kernel's `authencesn` cryptographic template via `AF_ALG` + `splice()`.
> Disclosed April 29, 2026 by Theori (Xint Code).
---
## Overview
| Field | Detail |
|---|---|
| **CVE** | CVE-2026-31431 |
| **Nickname** | Copy Fail |
| **CVSS** | 7.8 HIGH |
| **Type** | Local Privilege Escalation (LPE) |
| **Introduced** | Linux kernel 4.14 (2017, commit `72548b093ee3`) |
| **Fixed** | Mainline commit `a664bf3d603d` |
| **Requires** | Local unprivileged shell access |
| **Remote vector** | None โ local only |
---
## Vulnerability Summary
A logic flaw in the kernel's `authencesn` AEAD wrapper allows an unprivileged local user to perform a **deterministic, controlled 4-byte write into the page cache of any readable file** on the system โ including setuid binaries such as `/usr/bin/su`.
The root cause is a 2017 in-place processing optimization that placed page cache pages into a writable scatterlist. The `authencesn` algorithm writes 4 bytes of scratch data outside its intended output region during Extended Sequence Number rearrangement. Because of the scatterlist structure introduced by the optimization, those 4 bytes land in the page cache of a file fed via `splice()` โ bypassing file permissions entirely.
**No race condition. No retries. No crash risk. Deterministic across all tested distributions.**
### Comparison to Prior Art
| | Dirty Cow (2016) | Dirty Pipe (2022) | **Copy Fail (2026)** |
|---|---|---|---|
| Race condition required | Yes | Partial | **No** |
| Version-specific | Yes | Yes | **No** |
| Reliability | Flaky | Moderate | **Deterministic** |
| Distro coverage | Limited | Limited | **All since 2017** |
---
## Affected Versions
**Vulnerable:** Linux kernel 4.14 through 6.18.21 and 6.19.x before 6.19.12.
All major distributions shipping kernels in this range are affected, including:
| Distro | Tested Version |
|---|---|
| Ubuntu 24.04 LTS | 6.17.0-1007-aws |
| Amazon Linux 2023 | 6.18.8-9.213.amzn2023 |
| RHEL 10.1 | 6.12.0-124.45.1.el10_1 |
| SUSE 16 | 6.12.0-160000.9-default |
**Not affected:** Ubuntu 26.04 (Resolute) and later.
---
## Mitigation
### Option 1 โ Patch (Recommended)
Update to a kernel containing mainline commit `a664bf3d603d`, which reverts the 2017 in-place optimization.
```bash
# Ubuntu / Debian
sudo apt update && sudo apt upgrade -y && sudo reboot
# RHEL / AlmaLinux / Amazon Linux
sudo dnf clean metadata && sudo dnf upgrade && sudo reboot
# SUSE
sudo zypper refresh && sudo zypper update kernel-default && sudo reboot
```
### Option 2 โ Disable `algif_aead` (Temporary)
If patching immediately is not possible, disable the vulnerable module to close the attack surface.
> **Note for RHEL-family systems:** `algif_aead` is built into the kernel on RHEL/AlmaLinux/CentOS (`CONFIG_CRYPTO_USER_API_AEAD=y`). The `modprobe.d` workaround **does not work** on these systems. Use the `initcall_blacklist` method instead.
**Debian/Ubuntu (module is loadable):**
```bash
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || true
```
**RHEL-family (built-in kernel โ requires reboot):**
```bash
sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot
```
Confirm after reboot:
```bash
grep initcall_blacklist /proc/cmdline
```
### What This Workaround Affects
| Component | Impact |
|---|---|
| dm-crypt / LUKS | โ Not affected |
| SSH | โ Not affected |
| IPsec / XFRM | โ Not affected |
| kTLS / in-kernel TLS | โ Not affected |
| OpenSSL / GnuTLS / NSS (default builds) | โ Not affected |
| OpenSSL with `afalg` engine explicitly enabled | โ ๏ธ Falls back to userspace crypto |
| Applications binding `aead`/`skcipher`/`hash` AF_ALG sockets directly | โ ๏ธ Will break โ check with `lsof \| grep AF_ALG` |
### Option 3 โ seccomp (Defense-in-Depth)
For untrusted workloads โ containers, CI runners, sandboxed environments โ block `AF_ALG` socket creation via seccomp policy regardless of patch state. This limits the attack surface even on vulnerable kernels.
---
## Detection
Check if `algif_aead` is currently loaded or in use:
```bash
# Check if module is loaded
lsmod | grep algif_aead
# Check if any process has an AF_ALG socket open
lsof | grep AF_ALG
ss -xa | grep alg
```
Runtime detection signatures are available in Sysdig Secure (rule: `AF_ALG Page Cache Poisoning Leading to Privilege Escalation`).
---
## References
| Resource | Link |
|---|---|
| NVD Entry | https://nvd.nist.gov/vuln/detail/CVE-2026-31431 |
| Theori Full Writeup | https://xint.io/blog/copy-fail-linux-distributions |
| Copy Fail Site | https://copy.fail |
| CERT-EU Advisory | https://cert.europa.eu/publications/security-advisories/2026-005/ |
| Sysdig Analysis | https://sysdig.com/blog/cve-2026-31431-copy-fail-linux-kernel-flaw-lets-local-users-gain-root-in-seconds |
| The Register Coverage | https://theregister.com/2026/04/30/linux_cryptographic_code_flaw/ |
| AlmaLinux Patch Notes | https://almalinux.org/blog/2026-05-01-cve-2026-31431-copy-fail/ |
| CloudLinux KernelCare | https://blog.cloudlinux.com/cve-2026-31431-copy-fail-kernel-update |
---
## Disclosure Timeline
| Date | Event |
|---|---|
| 2017 | Regression introduced via commit `72548b093ee3` |
| Early April 2026 | Upstream fix merged (commit `a664bf3d603d`) |
| April 29, 2026 | Public disclosure by Theori / Xint Code |
| April 30, 2026 | Distribution patches begin shipping |
| May 1, 2026 | AlmaLinux patched kernels in production repos |
---
## Author
**xD The Watcher** โ Red Teamer, Ethical Hacker & AI Security Researcher
GitHub: [@xd20111](https://github.com/xd20111)
Blog: [yourhacker](https://yourhacker.in)
---
## Notes
This repository documents the vulnerability for research and defensive purposes. For the authoritative technical writeup and official PoC, refer to Theori's disclosure linked above.
If your threat model includes shared-kernel multi-tenancy โ containers on a shared host, CI runners, build farms โ the isolation boundary is now meaningfully weaker until patched. Hardware or VM-level isolation is the correct response, not namespace boundaries.