0 Your Cart $0.00

Cart (0)

No products in the cart.

CVE-2026-31431: The "Copy Fail" Linux Kernel Vulnerability

Disclosed: April 29, 2026 Nickname: Copy Fail Severity: HIGH CVSS Score: 7.8 Read time: 8 min Tags: Linux, Security, CVE, Kernel, Privilege Escalation

A high-severity local privilege escalation vulnerability has been disclosed in the Linux kernel, affecting virtually every major Linux distribution released since 2017.

Nicknamed "Copy Fail" and tracked as CVE-2026-31431, it was discovered and disclosed by security researchers at Theori on April 29, 2026.

The flaw allows an unprivileged local user to gain root access in seconds using a tiny Python script — no race conditions, no special tools, no compiled payloads required.

What Is Copy Fail?

Copy Fail is a logic bug in the Linux kernel's authencesn cryptographic template.

It exploits the interaction between the kernel's AF_ALG crypto interface and the splice() system call to write four controlled bytes into the page cache of any readable file on the system.

The page cache is what the kernel actually reads when loading a binary for execution.

By corrupting the in-memory cached copy of a privileged setuid binary — such as /usr/bin/su — An attacker can make the kernel execute a modified version of that binary without ever changing the file on disk.

This is what makes Copy Fail particularly dangerous: the file on disk remains completely untouched, so standard disk-based integrity checks and forensic tools will detect nothing.

How Did This Bug Get Into the Kernel?

The vulnerability did not appear in a single commit. It is the result of three separate, individually reasonable changes made to the kernel over several years.

2011 — authencesn was added to the kernel as an AEAD cryptographic wrapper used by IPsec.

2015 — AF_ALG AEAD socket support was introduced, exposing the kernel's AEAD ciphers to userspace through a socket interface.

2017 — An in-place optimization was added to algif_aead.c via commit 72548b093ee3. This optimization set req->src = req->dst, meaning both the source and destination scatter-gather lists pointed to the same memory region.

The 2017 optimization is the root cause.

After this change, when userspace feeds the socket through splice(), the tag pages from the source scatterlist get chained into the output scatterlist. Those tag pages reference the page cache of the spliced file.

The authencesn(hmac(sha256),cbc(aes)) algorithm then writes four bytes of scratch space for Extended Sequence Number rearrangement — and because of the flawed scatterlist layout, that write lands inside the spliced file's cached data in memory, bypassing the file's permissions entirely.

The Exploit

The proof-of-concept exploit released by Theori is a 10-line, 732-byte Python script.

It uses only standard Python library modules: os, socket, and zlib.

It requires Python 3.10 or later for os.splice().

There is no compiled payload. No additional software needs to be installed. No kernel modules need to be loaded beyond what ships by default.

The script targets a setuid binary, corrupts its in-memory cached copy, and gains root access.

Tested distributions with working exploits include:

  • Ubuntu 24.04
  • Amazon Linux 2023
  • RHEL 10.1
  • SUSE 16

The same script works across all of them without any per-distribution modifications, offsets, or version checks.

Why Copy Fail Is Especially Serious

No Race Condition Required

Previous high-profile Linux kernel privilege escalation vulnerabilities required winning a race condition.

Dirty Cow (CVE-2016-5195) required racing the VM subsystem's copy-on-write path. It needed multiple attempts and sometimes crashed the system.

Dirty Pipe (CVE-2022-0847) required precise pipe buffer manipulation and was version-specific.

Copy Fail is a straight-line logic flaw. It triggers deterministically, every single time, without races, retries, or crash-prone timing windows.

No Forensic Trace on Disk

The kernel never marks the corrupted page dirty for writeback.

The file on disk remains unchanged. Standard disk-based checksum tools and integrity monitors will see no modification.

The corrupted version exists only in memory. A reboot or sufficient memory pressure causes the page cache to reload the original, clean file from disk.

No Detection by File Monitoring Tools

Because the exploit bypasses the ordinary VFS write path, tools that monitor files using inotify — a common mechanism for detecting file tampering — will not be triggered.

Container Escape Potential

The page cache is shared across the host.

This means the vulnerability represents a potential container escape primitive that could affect Kubernetes nodes.

An attacker with code execution inside a container could use Copy Fail to corrupt page cache entries visible to the host, potentially escaping the container boundary entirely.

Who Is Affected?

Copy Fail affects the Linux kernel from version 4.14 through 7.0-rc, covering:

  • All kernel 6.18.x releases prior to 6.18.22
  • All kernel 6.19.x releases prior to 6.19.12
  • Older LTS lines: 6.12.x, 6.6.x, 5.15.x, 5.10.x

In practical terms, this means every Linux distribution using a kernel released since July 2017 is affected.

Note: Ubuntu 26.04 (Resolute) and later kernels are not affected.

CVE Details at a Glance

FieldDetail
CVE IDCVE-2026-31431
NicknameCopy Fail
DisclosedApril 29, 2026
Discovered byTheori
CVSS Score7.8 (HIGH)
Attack VectorLocal
Privileges RequiredNone (unprivileged user)
Affected ComponentLinux kernel algif_aead / authencesn
Kernels Affected4.14 through 7.0-rc (pre-patch)
Exploit AvailableYes — public PoC on GitHub
CISA KEV ListedNo (as of April 30, 2026)

Comparison With Similar Vulnerabilities

VulnerabilityRace ConditionVersion SpecificPortableDisk Forensic Trace
Dirty Cow (CVE-2016-5195)YesNoPartialYes
Dirty Pipe (CVE-2022-0847)NoYesNoYes
Copy Fail (CVE-2026-31431)NoNoYesNo

Patch and Remediation

The fix reverts the 2017 in-place optimization entirely, switching algif_aead.c back to out-of-place operation.

The relevant upstream commit is fafe0fa2995a, tagged with a Fixes: reference pointing to 72548b093ee3 — the original 2017 commit that introduced the flaw.

Distribution patch status (as of April 30, 2026):

  • Debian — Patch released
  • Ubuntu — Patch released
  • SUSE — Patch released
  • Red Hat / RHEL — Initially planned to defer; later updated to patch promptly
  • Amazon Linux — Patch in progress

The recommended action is to update your kernel as soon as your distribution provides a patched package.

Temporary Mitigation (If You Cannot Patch Immediately)

If a patched kernel is not yet available for your distribution, you can disable the vulnerable algif_aead kernel module as a temporary workaround.

Disable the module persistently:

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

Check if any process is currently using AF_ALG sockets:

lsof | grep AF_ALG

Important caveats about this mitigation:

  • This does not affect dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, or SSH under normal configurations.
  • Applications explicitly configured to use the afalg engine or that bind AEAD/skcipher/hash sockets directly may be affected.
  • Applications should gracefully fall back to userspace cryptographic functions, but some may not support this and may require a reboot to trigger the fallback.

Warning: If the vulnerability has already been exploited on your system, this mitigation will not remediate any pre-existing compromise. Full incident response procedures should be followed in that case.

Who Is Most at Risk?

The vulnerability is of most immediate concern to:

  • Multi-tenant Linux systems — shared servers where multiple users have local accounts
  • CI/CD runners — systems that execute untrusted code from pull requests or external contributors
  • Kubernetes nodes — due to the container escape potential via the shared page cache
  • Shared-kernel container environments — any setup where containers share the host kernel

For systems where only a single trusted user has local access, the practical risk is lower — but patching is still strongly recommended.

Detection

Standard disk-based forensic tools will not detect exploitation of Copy Fail, since no files on disk are modified.

Detection requires runtime monitoring of kernel behavior.

Security vendors including Sysdig have deployed detection rules targeting the specific system call sequence used by the exploit: socket, setsockopt, splice, sendmsg, recvmsg combined with AF_ALG socket usage patterns consistent with page cache poisoning.

CERT-EU strongly recommends applying the relevant kernel update as soon as possible, prioritizing Kubernetes nodes and CI/CD runners.

Timeline

DateEvent
2011authencesn added to Linux kernel
2015AF_ALG AEAD socket support introduced
July 2017In-place optimization added via commit 72548b093ee3 — root cause introduced
Early April 2026Upstream fix committed (fafe0fa2995a)
April 29, 2026CVE-2026-31431 publicly disclosed by Theori
April 30, 2026Debian, Ubuntu, SUSE release patches
April 30, 2026Red Hat updates guidance to patch promptly

Final Thoughts

Copy Fail is a sobering reminder that critical security vulnerabilities do not always come from memory corruption bugs or sophisticated exploitation techniques.

This one came from a nine-year-old optimization in a cryptographic module, the silent interaction of three unrelated kernel changes, and an assumption that was never documented and never enforced.

The result is a vulnerability that affects nearly every major Linux distribution released in the last decade, can be exploited with a 732-byte Python script, leaves no forensic trace on disk, and works reliably every single time.

If your systems run Linux kernels released since 2017 — and the vast majority do — patching should be treated as urgent.

Apply the kernel update from your distribution the moment it becomes available, and in the meantime, disable the algif_aead module as a temporary mitigation.

Stay patched. Stay secure.

Live Chat Online

Hi there! How can we help you today?

Glad you’re here.