Copy Fail technical analysis: AF_ALG, splice and page cache behind CVE-2026-31431

April 29, 2026

Technical illustration of AF_ALG, splice and page cache in Copy Fail

Copy Fail, CVE-2026-31431, is a local privilege escalation vulnerability in the Linux kernel. The short version is that a combination of AF_ALG, splice(), the authencesn crypto template and an in-place algif_aead optimization allows a controlled 4-byte write into page cache. The useful version for security teams is less dramatic and more operational: this is a boundary failure between scatterlists that should never have shared a writable destination.

The sensitive piece is AF_ALG, the socket interface that exposes kernel crypto primitives to userspace. With splice(), userspace can move data from a file into a pipe without copying every byte. Along that path, the kernel may keep references to page-cache pages. When those pages end up chained into a scatterlist that the crypto subsystem treats as a destination, the dangerous condition appears.

According to Xint Code’s analysis, authencesn uses part of the destination buffer as temporary scratch space to rearrange bytes related to ESN. That behavior made sense under its original assumptions, but became dangerous when combined with the AF_ALG AEAD in-place path introduced years earlier. The temporary write crosses the legitimate region and reaches pages representing the in-memory copy of a readable file.

Why page cache changes the impact

The page cache is not a private copy owned by the attacker process. It is the in-memory representation that other system paths may read. If that copy belongs to a setuid binary, a temporary memory change can affect execution without modifying the persistent file on disk. That is why checks based only on the physical file are not enough to reason about impact.

The reported change is small: 4 bytes per operation. But size does not define severity by itself. A small, reliable and repeatable primitive can be enough if the target is sensitive. The technical value of Copy Fail is the combination of control, reliability and portability across affected kernels and distributions, not the byte count of a PoC.

This also explains why the severity debate is reasonable. The issue requires local execution and does not provide initial remote access. That pushes several vendors toward medium or moderate priority. At the same time, in multi-tenant, CI, container and sandbox environments, the boundary between “local” and “critical” is thin: local code execution is exactly what those platforms provide.

The fix

The main fix returns algif_aead to out-of-place operation. Instead of allowing source and destination to share a combined structure with page-cache pages chained into it, the fix separates input and output scatterlists. That removes the condition that let the temporary authencesn write reach file-backed memory.

For operators, the practical message is clear: update the distribution kernel to a version that includes the fix. Manually carrying commits is not advisable unless the team maintains its own kernel and has a validation process. In normal fleets, the remediation unit is the vendor kernel package, AMI/base image, or managed cloud kernel.

As a temporary mitigation, the Copy Fail site recommends disabling algif_aead or blocking AF_ALG socket creation with policies such as seccomp for untrusted workloads. That is a reasonable surface reduction, especially for runners and sandboxes, but it should be tested. Some embedded environments or explicit crypto-offload configurations may depend on AF_ALG.

Defensive checklist

First, inventory actual kernels, not just distributions. Kernel versions, backports and cloud builds matter more than product names. Second, identify hosts where users, containers or CI jobs share a kernel. Those systems should be prioritized over single-user servers.

Third, review whether sandbox policies block unnecessary socket families. Many workloads never need to open AF_ALG; if your model runs third-party code, blocking unused surfaces reduces exploitation room beyond this specific incident. Fourth, separate runners for external code and avoid reusing privileged hosts for low-trust PRs or pipelines.

Fifth, validate against vendor advisories. The public discussion contains useful details, but also mistakes and disagreements, including the debated reference to a non-existent RHEL version on the public page. For change management, use official trackers and record state by platform.

What the patch does not solve

Patching Copy Fail does not eliminate the broader problem of running untrusted code on shared kernels. It does not replace strong isolation, syscall control, tenant separation or base-image rotation. The technical lesson is broader: in-place optimizations that mix references from different origins need careful review when zero-copy paths from userspace exist.

Teams maintaining platforms should review regression coverage around splice(), page cache, crypto APIs exposed to userspace and sandboxes that allow rarely used syscalls. Copy Fail shows how a locally reasonable decision can become dangerous when another subsystem changes the memory model years later.

The conclusion is not panic. It is priority. Wherever a potential attacker can already execute local code, such as CI, multi-tenant Linux, Kubernetes, shared desktops or development hosts, reliable local escalation is not a secondary detail. It is a trust-boundary failure.