## Overview

CVE-2026-31431, publicly named "Copy Fail", is a high-severity local privilege escalation vulnerability in the Linux kernel crypto subsystem disclosed on the oss-security mailing list on 2026-04-29 and analyzed in detail by Unit 42 (Palo Alto Networks) on 2026-05-05. The vulnerability is a deterministic four-byte arbitrary write into the kernel page cache reachable from any unprivileged local user via the AF_ALG socket interface. Unlike heap-grooming or race-condition LPEs, exploitation is deterministic — no retries, no offset guessing, 100% reliability on first attempt — and the public 732-byte Python proof-of-concept is portable across distributions without modification.

## Technical Root Cause

The Linux kernel exposes its hardware-accelerated crypto primitives to userspace through the AF_ALG socket family. Submodules like algif_skcipher, algif_aead, and algif_hash provide socket-based APIs to symmetric ciphers, AEAD modes, and hash algorithms. The `algif_aead` driver implements the AEAD (Authenticated Encryption with Associated Data) interface used by algorithms such as `gcm(aes)`, `ccm(aes)`, and the legacy ESN variant `authencesn(...)`.

In 2017, kernel commit `72548b093ee3` ("crypto: algif_aead - skip SGL entries with NULL page") introduced an "in-place" optimization for the `authencesn` algorithm path that allowed encryption to operate directly on user-supplied scatterlist memory rather than allocating an intermediate destination buffer. The optimization assumed that the source and destination pages were always private to the calling task and writable. That assumption is wrong: user pages submitted via `sendmsg(MSG_MORE)` may be shared, read-only, or — critically — backed by the kernel page cache (e.g. mmaps of files on tmpfs, executables, or shared libraries).

When the AEAD authentication tag (the trailing 16 bytes of the ciphertext, of which only four bytes are within the attacker-controlled associated-data length boundary on the ESN variant) is written back "in place", the kernel writes attacker-chosen bytes into a page-cache page belonging to a kernel-trusted file. Because the page cache is shared across all processes that map the same inode, the corruption is visible to every subsequent reader — including the kernel's binfmt loader.

## Exploitation Chain

1. **Setup** — The attacker opens an `AF_ALG` socket, binds it with `sockaddr_alg.salg_type = "aead"` and `salg_name = "authencesn(hmac(sha1),cbc(aes))"`, sets a key with `setsockopt(SOL_ALG, ALG_SET_KEY, ...)`, and `accept()`s a child socket for the operation handle. 2. **Cache Hydrate** — The attacker reads `/usr/bin/su` (or `sudo`/`passwd`) so the relevant page is loaded into the page cache, then `mmap`s the file `MAP_SHARED | PROT_READ`. 3. **Submit** — The attacker calls `sendmsg(MSG_MORE)` on the AEAD socket with the mmap'd page as the source iovec, supplying an attacker-chosen four-byte tag value and the precise associated-data length that will steer the in-place write to the offset of the setuid check inside the binary. 4. **Trigger** — A single read on the operation socket triggers the kernel to perform the encrypt-and-tag operation. The four-byte tag is written into the page-cache page covering `/usr/bin/su`. 5. **Escalate** — The attacker `exec`s `/usr/bin/su`. The loader maps the corrupted page-cache copy. The patched bytes neutralize the credential check, and the binary preserves its setuid-root file mode — the attacker now has UID 0. 6. **Cleanup** — Page-cache eviction (memory pressure or `echo 1 > /proc/sys/vm/drop_caches`) restores the on-disk copy. There is no forensic artifact on disk; only volatile memory carries evidence of the modification.

## Why It Is Deterministic

Copy Fail does not rely on a heap spray, a TOCTOU race, or KASLR brute-force. The page-cache offset of any setuid binary is trivially derivable from `/proc/[pid]/maps` (no privilege required) and the algif_aead in-place path follows a fully deterministic control-flow once the algorithm name and associated-data length are fixed. The attacker writes the exact bytes they intend, at the exact offset they intend, on every kernel where the optimization is present. This is what makes Copy Fail comparable to Dirty Cow (CVE-2016-5195) and Dirty Pipe (CVE-2022-0847) in significance, but materially more reliable than either.

## Container and Multi-Tenant Impact

In a Kubernetes or shared-tenancy environment, all containers on a node share the host's kernel page cache. A compromised pod that hydrates and corrupts `/usr/bin/su` in the page cache corrupts that page for every other pod and the host itself, because Linux page-cache pages are keyed on `(inode, offset)` and inodes are shared by bind-mounted images. This collapses the container security boundary entirely: a pod with default capabilities can take over the host and every neighbor pod, with no on-disk artifact to detect.

## Affected Versions

The vulnerable optimization is present in every Linux kernel from 4.14 (where commit 72548b093ee3 was merged) through 6.19.12 inclusive. Distributions confirmed vulnerable include Ubuntu (all LTS in support), Amazon Linux 2 and 2023, RHEL 8/9/10, Debian 11/12/13, SUSE SLES 15, and AlmaLinux 8/9/10. Hardened kernels with `CONFIG_USER_NS=n` or seccomp profiles that block `socket(AF_ALG, ...)` are not exploitable; the latter is the recommended short-term mitigation.

## Patch

The upstream patch is commit `a664bf3d603d` ("crypto: algif_aead - revert in-place optimization"), which reverts `72548b093ee3` and restores the explicit destination-buffer copy. Distributions began shipping fixed kernels on 2026-05-06. There is no workaround that preserves the in-place fast-path; the optimization is unsafe in any form that does not validate page ownership, and a defense-in-depth seccomp filter is the recommended interim control until patched kernels are deployed everywhere.

## Detection Posture

Because the corruption lives in the page cache, traditional file-integrity monitoring (AIDE, Tripwire, auditd `-w /usr/bin/su -p wa`) will not flag the modification: the on-disk file is never touched. Detection must focus on (a) anomalous use of the `AF_ALG` socket family by non-crypto-aware processes, (b) auditd `execve` events where a setuid binary is invoked by an unprivileged ancestor and immediately yields a euid=0 child, and (c) eBPF instrumentation of `aead_recvmsg` or `algif_aead`-tagged kmem_cache allocations. See accompanying detections for SPL, KQL, and Sigma rules.