CopyFail CVE-2026-31431: Linux root, AF_ALG and a safe PoC

CopyFail, tracked as CVE-2026-31431, is a local privilege-escalation vulnerability in the Linux kernel. It is not a conventional buffer overflow or a bug in a peripheral driver. The flaw joins the AF_ALG userspace cryptography interface, the authencesn AEAD implementation, data-copying semantics and the page cache. A user already able to execute code on an affected host can turn that interaction into a controlled modification of data backed by a read-only file and ultimately obtain root privileges.

That boundary is important: CopyFail is not standalone remote code execution. An attacker first needs local code execution through a compromised account, a vulnerable application, malicious software or a workload sharing the affected kernel. In a real intrusion, however, the flaw can collapse the distance between “I have an unprivileged shell” and “I control the host.”

What has been confirmed

Theori and Xint publicly disclosed the issue on 29 April 2026. Their timeline says maintainers received the report on 23 March, a patch was proposed on 25 March, the fix reached mainline on 1 April and the CVE was assigned on 22 April. The regression originated in 2017 optimisation commit 72548b093ee3; fix commit a664bf3d603d reverted the unsafe logic.

Microsoft published its technical assessment on 1 May and noted preliminary testing activity. CISA added CVE-2026-31431 to the Known Exploited Vulnerabilities catalogue. Those facts are stronger prioritisation signals than a base score alone: defenders should not leave CopyFail in an ordinary quarterly patch queue.

The researchers’ public Python exploit is 732 bytes and has SHA-256 a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952df05c719aa3911687f9. Theori reports reliable operation across several major distributions. That is a researcher claim rather than a guarantee for every kernel build or vendor backport. The canonical code is available in Theori’s repository; this article deliberately does not reproduce the chain that alters a setuid executable.

How a cryptographic operation reaches a read-only file

Linux exposes kernel cryptographic algorithms to userspace through AF_ALG sockets. A program selects an operation type, algorithm, key and parameters, then sends data using socket-like semantics. algif_aead handles authenticated encryption with associated data. authencesn is one of the templates combining encryption and authentication.

High-performance implementations avoid copies wherever possible. An in-place operation uses the same storage as both source and destination. That is safe only when the implementation observes buffer boundaries, offsets, ownership and aliasing exactly. CopyFail breaks that assumption: with a carefully arranged input and lengths, the AEAD path can write output into a page derived from a file’s page cache.

splice() matters because it moves data between file descriptors while avoiding a conventional userspace copy. splice() is not itself the vulnerability. It is a useful link in the chain because it presents page references to the flawed cryptographic path. The outcome bypasses the ordinary filesystem write check: a user without write permission causes a cache-backed page to change.

The public exploit selects a readable setuid executable and replaces part of a page. Executing the modified image then creates a privileged process. This is why the final impact extends to the host’s confidentiality and integrity. A read-only mount or the absence of write permission on the binary is not a sufficient control against this vulnerability class.

Safe PoC: demonstrate aliasing without privilege escalation

The following demonstrator does not call AF_ALG, does not use splice(), does not touch a setuid file and cannot grant root. It models only the underlying design hazard: two logical roles that appear separate can reference the same memory, allowing an incorrect in-place operation to mutate an object that was expected to remain read-only.

from pathlib import Path
import tempfile

original = b"READ_ONLY_PAGE:0123456789abcdef"

with tempfile.TemporaryDirectory(prefix="copyfail-safe-") as directory:
    sample = Path(directory) / "ordinary-user-file.bin"
    sample.write_bytes(original)

    # Model a cache page: two logical roles alias one mutable buffer.
    page = bytearray(sample.read_bytes())
    crypto_source = memoryview(page)
    crypto_destination = memoryview(page)

    # Harmless four-byte change in a disposable user-owned file.
    crypto_destination[15:19] = b"DEMO"
    sample.write_bytes(page)

    assert bytes(crypto_source) == sample.read_bytes()
    assert sample.read_bytes() != original
    print("SAFE DEMO: an aliased destination changed the shared page")
    print(sample.read_bytes())

This code does not test the kernel vulnerability; it visualises the aliasing failure. Establish exposure by comparing the installed kernel package with the distribution advisory. If exploit validation is necessary, use a disposable isolated lab image with written authorisation. Do not run the public exploit against production “to see whether it works”: it intentionally modifies a privileged executable and can leave the host untrustworthy.

Establish exposure safely

Collect the active kernel and its distribution identity first:

uname -a
cat /etc/os-release
cat /proc/sys/kernel/osrelease

Then consult the bulletin for that specific distribution. Upstream version comparisons alone are unreliable because Debian, Ubuntu, Red Hat, SUSE, Amazon Linux and appliance vendors backport security fixes without adopting the newest mainline version. Evidence of remediation is the vendor’s fixed package or a confirmed backport, not a scanner that only parses uname.

You can gather supporting information about algif_aead:

grep -w algif_aead /proc/modules
modinfo algif_aead 2>/dev/null

An unloaded module does not prove safety. It may be loadable, the functionality may be compiled in, or the host policy may change. Treat module state as inventory context, not a conclusive vulnerability test.

Remediation order

Install a vendor kernel package containing the fix and reboot into it. Installing an RPM or DEB does not replace the code currently executing in memory. After reboot, match uname -r to the expected package and cover standby nodes, VM templates, container hosts, recovery systems and autoscaling images.

The researchers proposed disabling algif_aead as a temporary mitigation. Test the change for application dependencies and persist it using the distribution’s supported mechanism. It does not replace patching. Priority is especially high on multi-user systems, CI runners and platforms that execute customer-controlled workloads on a shared kernel.

A practical response sequence is:

1. inventory physical hosts, VMs, Kubernetes nodes, bastions, runners and Linux-based appliances;
2. deploy the vendor update and reboot every active path;
3. rebuild ephemeral instances from a corrected golden image;
4. reduce untrusted local execution and unnecessary kernel interfaces;
5. treat a known foothold on a vulnerable machine as a possible root compromise.

Detection: there is no single magic IOC

The exploit is brief and uses legitimate system calls. Detection should correlate process anomalies, file integrity, privilege changes and user context. Useful signals include unusual processes under service accounts, AF_ALG socket creation, splice activity, execution of setuid files from an unexpected parent chain and EDR alerts involving an executable image changing in memory.

If binary integrity is in doubt, do not rely solely on rereading a file from the same running system. Preserve memory and logs, compare installed packages with a trusted repository, use IMA or fs-verity evidence where deployed and rebuild from a known image when escalation is plausible. A page-cache overwrite may not remain as a simple on-disk diff, but a process launched from the altered page could already have installed persistent access.

The Linux hardening lesson

CopyFail demonstrates that “read-only file” is not an absolute boundary when privileged kernel code mishandles aliased memory. Defence in depth still changes the outcome: rapid kernel patching, minimal images, restricted accounts, short-lived nodes, integrity monitoring and segmentation reduce both the chance of an initial foothold and the blast radius of local escalation.

Add the flaw to your vulnerability-management process, and assess shared-kernel platforms alongside Linux hardening and container security. For controlled remediation validation without risking production, contact BreachRoad.

---

Primary sources: Theori/Xint — CopyFail, canonical PoC repository, Microsoft Security Blog, CERT-EU 2026-005, CISA KEV.