Linux Kernel "Copy Fail" (CVE-2026-31431) — Local Privilege Escalation Affecting Nearly Every Distro Since 2017, and Practical Mitigations

Copy Fail (CVE-2026-31431, CVSS 7.8) is a Linux kernel local privilege escalation disclosed at the end of April 2026. It is a logic bug in the algif_aead module — the AEAD socket interface in the kernel's userspace crypto API (AF_ALG) — that lets an unprivileged local user trigger a deterministic 4-byte write into the page cache of any file readable on the system. Public reports describe a roughly 732-byte Python script that flips a setuid binary and yields root, with reliability that is deterministic rather than probabilistic.

The root cause is a 2017 commit (around `72548b093ee3` in the 4.14-era mainline) that switched AEAD operations to in-place. After that change, input and output scatterlists pointed at the same memory, so pages in the read-side page cache became visible to the crypto layer as a writable destination. The optimization that "skipped the copy" broke the safety boundary — hence the moniker "Copy Fail."

Because the offending commit landed in 4.14 (2017), virtually all Linux distributions shipped since then are in scope. Public material specifically calls out: - Ubuntu 24.04 LTS - Amazon Linux 2023 - Red Hat Enterprise Linux 14.3 - SUSE 16 Assume any other major distro running a stock kernel with algif_aead enabled is also affected unless explicitly verified otherwise.

Compared to typical kernel LPEs, the operational risk is unusually high because: - No race window: pure logic flaw, no contention to wait on - No offset guessing: no leak / ASLR estimation needed - Same script across distros: one exploit covers many OSes - Heavy impact in shared / multi-tenant Linux: hosts, CI runners, jump boxes - Target is page-cache-backed read-only files: directly flip bytes in a setuid binary, then execute

The upstream patch reverts the 2017 in-place optimization, returning AEAD operations to out-of-place (input and output scatterlists separate). This removes the structural condition where page-cache pages appear as writable destinations to the crypto layer. Public material lists fixed versions in the 6.18.22 / 6.19.12 / 7.0 series. Distributions are backporting and shipping vendor kernels.

What to do, in priority order: 1. Apply the vendor kernel update and reboot (top priority): install the patched kernel (or LTS backport) from your distro and confirm with `uname -r`. 2. For hosts that can't reboot immediately, disable algif_aead: persistent module blacklisting (commands below) shrinks the attack surface. 3. Broader containment: deny `socket(AF_ALG, ...)` via seccomp at the application or container-runtime profile. 4. Detection / audit: monitor `algif_aead` load events, unusual AF_ALG syscall patterns, and integrity-check setuid binaries (AIDE, OSSEC, or your own hash compare).

Persistent block of algif_aead

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
sudo rmmod algif_aead 2>/dev/null || true

This prevents future loads of `algif_aead` and tries to unload the currently loaded module (will fail if in use; investigate dependencies or schedule a reboot in that case). Verify

lsmod | grep algif_aead
cat /etc/modprobe.d/disable-algif.conf

Impact note: applications using AF_ALG / algif_aead are uncommon (some crypto libraries, specialized dm-crypt setups). Most general-purpose servers and containers tolerate the disable cleanly — but check anywhere crypto middleware is in play.

Containers share the host kernel, so an unprivileged user inside a container can still pivot to the host: - Managed Kubernetes (EKS / GKE / AKS): vendor pushes kernel-updated node images. Roll node pools sooner rather than later. - Self-managed K8s / Nomad: schedule node-kernel updates and rolling reboots. - Multi-tenant PaaS / shared CI: ship a seccomp profile that denies `socket(AF_ALG, ...)` while patches roll out. - AWS / GCP / Azure: track each provider's advisory + detection rules (Inspector, Defender for Cloud, etc.).

For our own infrastructure and engagements where we run customer infrastructure, we are doing this: 1. Watch vendor advisories; apply patched kernels and reboot as soon as available 2. Where reboot windows are constrained, apply the algif_aead module block as the first-pass mitigation 3. Re-baseline setuid-binary hashes for tamper detection 4. Prioritize shared hosts, CI runners, and jump boxes — anywhere unprivileged users persist For customers using our Network Systems or Software Development engagements with infra ops in scope, we can provide a tailored impact assessment and patch plan. Contact if you'd like one.

Q1: Do I need to act on personal Linux desktops too? A: Yes. LPEs are the classic "last step" once an attacker gains an unprivileged foothold via a browser bug, malicious package, or SSH compromise. Patch desktops too. Q2: What apps actually use AF_ALG? A: Few. Some dm-crypt setups, specific crypto libraries, and some kTLS paths. Most web / DB / app servers do not depend on algif_aead, so the side effects of disabling it are usually minimal. Q3: My container image kernel is old — is that the risk? A: The risk is the host kernel, not the container image. Containers share the host kernel; patch the host. Q4: When can I re-enable algif_aead? A: Once `uname -r` and your distro's kernel changelog confirm the patched kernel is running, you can re-enable it if any application requires it. Most environments leave it disabled with no downside. Q5: Detection signals? A: Unusual AF_ALG socket creation patterns, setuid binary hash changes, or auditd rules covering `socket(AF_ALG, ...)`.

- oss-security: CVE-2026-31431: CopyFail (openwall.com, initial disclosure, 2026-04-29) - Copy Fail: 732 Bytes to Root on Every Major Linux Distribution (Xint) - Nine-year-old Linux kernel flaw enables reliable LPE (Help Net Security) - New Linux 'Copy Fail' Vulnerability (The Hacker News) - What we know about Copy Fail (Bugcrowd) - CVE-2026-31431: "Copy Fail" Linux kernel flaw (Sysdig) - CERT-EU 2026-005 High Vulnerability in the Linux Kernel - Debian Security Tracker: CVE-2026-31431