Linux

Copy Fail, The Nine-Year Linux Kernel Flaw That Gives Any User Root in Seconds

Cybersec Sentinel

May 1, 2026 • 9 min read


Group	No attributed threat actor. Vulnerability discovered by Xint Code (Theori). Public PoC released April 2026.
Type	Local Privilege Escalation (LPE), Linux Kernel Logic Flaw, Container Escape Primitive
CVEs	CVE-2026-31431 (Linux kernel algif_aead page-cache corruption enabling root access, CVSS 7.8)
Malware	No associated malware family. Public 732-byte Python PoC (`copy_fail_exp.py`) actively circulating.
Score	🔴 9.3 Critical. CVSS 7.8 base elevated by public PoC, near-universal Linux exposure, reliable container escape capability, and patches still rolling out across major distributions.
Observed	1 May 2026

Overview

Copy Fail is a logic flaw in the Linux kernel's authencesn cryptographic template that has sat silently in the codebase since August 2017. Tracked as CVE-2026-31431 with a CVSS score of 7.8, it allows any unprivileged local user to write four controlled bytes into the page cache of any readable file on the system and use that primitive to gain root. A public proof-of-concept weighing just 732 bytes accomplishes this on Ubuntu, Amazon Linux, RHEL, and SUSE without a race condition, without kernel-specific offsets, and without crashing the system.

The flaw was surfaced by Xint Code, the security research arm of Theori, during approximately one hour of automated scanning of the Linux crypto/ subsystem. Xint reported the vulnerability to the Linux kernel security team on 23 March 2026. The mainline patch was committed on 1 April 2026 and the CVE was assigned on 22 April 2026. Public disclosure followed on 29 April 2026 at copy.fail, accompanied by a working exploit published to GitHub.

What distinguishes Copy Fail from typical Linux local privilege escalation bugs is its reliability. Most kernel LPEs require threading a race window or calculating per-distribution memory offsets. Copy Fail is deterministic. The same script runs unmodified across every mainstream Linux distribution that shipped a kernel built after August 2017. Researchers describe the exploit as straight-line logic with no retry loop and no timing sensitivity.

The practical blast radius is significant. The page cache is shared across the host kernel, meaning the exploit is not confined to the process or container that triggers it. In Kubernetes clusters, shared CI runners, multi-tenant shell hosts, and cloud environments executing user-supplied code, a single unprivileged account can leverage Copy Fail to compromise the node and cross tenant boundaries. Defenders running unpatched kernels on any of these workloads should treat this as a critical priority.

Key Details

Delivery Method – Local access. Requires an unprivileged user account on a vulnerable Linux host. No network access, no kernel debugging features, and no pre-installed primitives required. The kernel crypto API (AF_ALG) is enabled by default in essentially every mainstream Linux distribution.

Target – Any Linux system running a kernel built between August 2017 and the patch window (mainline commit a664bf3d603d). Confirmed affected distributions include Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16. Other distributions including Debian, Arch, Fedora, Rocky, AlmaLinux, and Oracle Linux running affected kernels behave identically. Highest risk environments: multi-tenant hosts, Kubernetes nodes, shared CI runners, and cloud SaaS platforms executing user-supplied code.

Functions

Triggers a deterministic, controlled 4-byte write into the page cache of any readable file on the system via the algif_aead kernel module
Edits the page cache backing a setuid binary (default: /usr/bin/su) without touching the on-disk file, bypassing file integrity monitoring tools
Spawns a root shell from the modified in-memory binary
Functions as a container escape primitive by leveraging the shared page cache across the host kernel
Operates without race conditions, memory offsets, or crash-prone timing windows

Obfuscation – The page-cache modification is in-memory only and not persistent across reboot. On-disk file integrity tools such as AIDE or Tripwire will not detect the modification as the binary on disk remains unchanged.

Attack Vectors

The vulnerability originates from an in-place optimisation introduced to algif_aead.c in kernel commit 72548b093ee3 in August 2017. This change allowed page-cache pages to be placed into a writable destination scatterlist during AEAD (Authenticated Encryption with Associated Data) operations. The oversight means that data intended only for reading can be written back to through the kernel's own crypto pipeline.

Stage 1 — Socket and splice setup: An unprivileged user opens an AF_ALG AEAD socket and configures it to use the authencesn template. They then use the splice() system call to pipe a page belonging to a setuid binary's memory-mapped page cache into the AEAD socket's transmit scatterlist. Because of the 2017 regression, the kernel places this read-only page cache entry directly into the writable destination scatterlist.

Stage 2 — Controlled page-cache write: The attacker crafts an AEAD operation that causes the kernel to write four attacker-controlled bytes back into the spliced page, corrupting the in-memory image of the setuid binary at a chosen offset. No locking conflicts or timing windows are involved. The operation completes deterministically in a single attempt.

Stage 3 — Privilege escalation: With the in-memory binary patched, the attacker invokes the setuid binary. Because the kernel executes the modified page-cache copy rather than re-reading from disk, the attacker's payload runs as root. The entire sequence is accomplished by a 732-byte Python script using only the standard library modules os, socket, and zlib. It requires Python 3.10 or later and no external dependencies.

In container environments, Stage 3 extends to a full container escape. Because the Linux page cache is shared between the host and all containers running on the same kernel, a container that completes Stage 2 successfully has modified a page visible to the host, enabling root access outside the container boundary.

Known Indicators of Compromise

Indicators may vary across campaigns and malware samples. Verify all IOCs against current threat feeds before actioning.

Public PoC File Hash

Indicator	Type	Notes
`a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952df05c719aa3911687f9`	SHA-256, `copy_fail_exp.py`	Official PoC published by Theori via GitHub and copy.fail

Kernel Commit References

Indicator	Type	Notes
`72548b093ee3`	Git commit hash	Regression commit introducing the flaw, August 2017
`a664bf3d603d`	Git commit hash	Official mainline fix, reverts algif_aead to out-of-place operation
`fafe0fa2995a`	Git commit hash	Additional fix revert commit

Affected Kernel Versions

Indicator	Type	Notes
`4.14` through `7.0-rc`	Kernel version range	Broadly vulnerable window
`6.18.x` prior to `6.18.22`	Kernel version	Vulnerable stable branch
`6.19.x` prior to `6.19.12`	Kernel version	Vulnerable stable branch

Suspicious Runtime Behaviour

Indicator	Type	Notes
`AF_ALG` socket creation (address family 38) by non-root user	AuditD event	High-confidence indicator when followed by splice()
`splice()` syscall from unprivileged process targeting setuid binary	AuditD event	Correlate with AF_ALG socket activity
Burst of ~40 AF_ALG socket operations from same UID within short window	Behavioural pattern	Matches exploit delivery loop

MITRE ATT&CK Techniques

Technique ID	Technique Name	Application in This Campaign
T1068	Exploitation for Privilege Escalation	Core technique: AF_ALG + splice() exploits algif_aead to corrupt page-cache of setuid binaries and obtain root
T1055	Process Injection	In-memory modification of setuid binary image without touching on-disk file
T1611	Escape to Host	Page-cache write crosses container boundaries, enabling node-level compromise from within a container
T1562.001	Impair Defences: Disable or Modify Tools	Page-cache corruption bypasses on-disk file integrity monitoring (AIDE, Tripwire)
T1059.006	Command and Scripting Interpreter: Python	Exploit delivered as a 732-byte Python 3 script with no external dependencies

Mitigation and Prevention

Apply the Kernel Patch Immediately

Update your distribution's kernel package to a version that includes mainline commit a664bf3d603d. This patch reverts the 2017 algif_aead in-place optimisation so that page-cache pages can no longer end up in the writable destination scatterlist. Confirm the fix is present by checking your kernel's git log or your distribution's changelog for a664bf3d603d or its backport equivalent. Fixed versions are kernel 7.0, 6.19.12, and 6.18.22.

Disable the algif_aead Module Before Patching

On systems where an immediate kernel update is not possible, disable the algif_aead module as an interim measure. Run echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf followed by rmmod algif_aead. Note: if algif_aead is compiled directly into the kernel rather than as a module, modprobe.d rules will have no effect and rmmod will appear to succeed without actually removing it. Verify module status with lsmod | grep algif_aead before assuming this mitigation is effective.

Block AF_ALG via Seccomp for Untrusted Workloads

For containers, CI runners, and any environment executing untrusted code, add a seccomp profile that blocks AF_ALG socket creation (socket family 38) regardless of whether the kernel is patched. This limits the exploit surface even if the underlying kernel is later found to have a bypass. Apply this to all container workloads at the runtime level via OCI runtime seccomp annotations.

Audit AF_ALG Socket Usage Before Disabling

Before blocking AF_ALG system-wide, run lsof | grep AF_ALG or ss -xa to identify any processes using the interface. The vast majority of systems will show nothing: dm-crypt, LUKS, kTLS, IPsec, OpenSSL, GnuTLS, and SSH all use the in-kernel crypto API directly and are unaffected by disabling algif_aead. The only workloads likely impacted are those explicitly using the OpenSSL afalg engine or applications binding AEAD sockets directly.

Deploy AuditD Detection Rules

Configure AuditD to log AF_ALG socket creation by non-root users (address family 38) and correlate these events with subsequent splice() syscalls against setuid binaries. A burst of approximately 40 AF_ALG operations within a short window from the same UID is a strong behavioural indicator of active exploitation. Feed these alerts into your SIEM with high-priority classification.

Deploy YARA Signatures

YARA signatures for Copy Fail exploit artefacts are available in the Neo23x0 signature-base repository (yara/expl_copy_fail_cve_2026_31431.yar). These detect known PoC code fragments, ELF shell payloads, AF_ALG and authencesn usage patterns, and references to the public PoC URL. Deploy these across endpoint detection, mail gateways, and file transfer inspection points.

Verify Container Runtime Isolation

If you operate Kubernetes clusters or shared container platforms, confirm that your container runtime enforces seccomp profiles that restrict AF_ALG socket creation. Pod Security Admission policies should block privileged pod specs on all production namespaces. Nodes running unpatched kernels should be cordoned from scheduling until they receive the kernel update.

Treat CI Runner Compromise as a Supply Chain Risk

Self-hosted GitHub Actions runners, GitLab runners, and Jenkins agents that execute pull request code on a shared kernel are fully exposed. An untrusted PR can escalate to root on the runner and potentially access secrets, signing keys, or deployment credentials stored on that host. Until runners are patched, consider switching to ephemeral runners that spin up a fresh kernel per job.

Risk Assessment

Copy Fail is notable less for its CVSS score of 7.8 than for its reliability and breadth. Nearly every Linux LPE discovered in recent years has carried reliability constraints: race windows that require dozens of attempts, per-distribution offsets that must be calculated, or kernel configurations that most distributions disable. Copy Fail has none of these constraints. The exploit is deterministic, runs on a single attempt, requires no prior knowledge of the target system's kernel configuration, and works identically across every major Linux distribution since 2017. The nine-year exposure window means the flaw is present in essentially all production Linux infrastructure worldwide.

The container escape dimension substantially elevates the real-world risk beyond the local CVSS score implies. In cloud-native environments, tenants are assumed to be contained by namespace and cgroup boundaries. Copy Fail collapses those boundaries by operating at the level of the shared page cache, which exists outside any namespace. A single compromised container in a Kubernetes cluster running an unpatched kernel can obtain root on the node, access secrets from other pods, and potentially pivot to the control plane depending on what credentials are accessible from the node. CI pipelines are equally exposed: a malicious contributor submitting a PR to a project with self-hosted runners can escalate to root on the runner in seconds.

The immediate availability of a working 732-byte public PoC means the exploitation barrier is extremely low. Any attacker with local shell access to an unpatched system, whether obtained through credential theft, web shell, or phishing, can now trivially complete the privilege escalation step. Organisations relying on least-privilege as a containment strategy need to treat every unpatched Linux host as potentially fully compromised once initial access is obtained.

Conclusion

The single most important action right now is patching the kernel. Check your distribution's advisory feed for packages containing commit a664bf3d603d or its backport, update immediately, and verify the fix is applied with a kernel version check. For any host that cannot be patched within the next 24 hours, disable algif_aead and verify the module is actually unloaded rather than built in.

Copy Fail demonstrates an increasingly common pattern in kernel vulnerability research: automated tooling surfacing logic flaws that manual code review missed for years. A flaw introduced in 2017 was exploitable for nearly a decade on every major Linux distribution before a researcher's automated scan found it in approximately one hour. The lesson for defenders is that kernel security can no longer be treated as a slow-moving discipline. Public PoCs for critical LPEs now arrive the same day as disclosure. Patching velocity and runtime detection coverage need to match that pace.