Why Copy Fail Is Different From Previous Linux Kernel Exploits

Go straight to an AI summary of this blog post instead

The Short Version

What: A Linux local privilege escalation called Copy Fail (CVE-2026-31431), a logic flaw in the kernel’s authencesn AEAD path reachable from userspace through the AF_ALG socket interface and splice(2).

Impact: A published 732-byte proof-of-concept can reliably elevate an unprivileged local user to root across major Linux distributions running vulnerable kernels.

Status: Patched kernels are shipping from AlmaLinux, Ubuntu, and other downstreams. CISA added CVE-2026-31431 to its Known Exploited Vulnerabilities catalog on May 1. CVSS 7.8 (HIGH).

Severity: Local vector, no privileges required, no user interaction, highly reliable exploitation. In many containerized or shared-execution environments, successful exploitation from within a container could lead to host-level compromise.

Do this now: Protect affected kernels immediately. Organizations using rebootless live patching can neutralize the exploit path without waiting for maintenance windows or reboots. Otherwise, deploy vendor-patched kernels as soon as operationally possible. If neither is immediately possible, temporarily disable the vulnerable AF_ALG AEAD path using the mitigation guidance below.

Copy Fail matters because it combines three properties defenders dislike seeing together: broad distro reach, highly reliable exploitation, and a public proof of concept released the same day as disclosure.

Am I Affected?

Almost certainly, unless you have already patched.

Copy Fail affects upstream Linux from kernel 4.14 onward, meaning nearly every actively maintained enterprise distribution inherited the vulnerable code path:

Ubuntu releases prior to Resolute (26.04)
Red Hat Enterprise Linux 8, 9, and 10
AlmaLinux 8, 9, 10, and Kitten 10
Rocky Linux, CentOS Stream, and Oracle Linux equivalents
Fedora (current and recent)
Debian stable and testing
openSUSE Tumbleweed and Leap
Most downstream rebuilds, including CloudLinux variants

The larger concern is the population outside actively maintained enterprise fleets: embedded Linux appliances, OEM kernels in networking gear, industrial systems, and end-of-life deployments that may never receive a patch. If a device has not received vendor kernel updates recently, assume it may remain permanently exposed.

The vulnerable path depends on the kernel exposing algif_aead, which is configured one of two ways depending on the distribution.

Quick check:


# Check if loaded as a module (Debian, Ubuntu, Arch-family)

lsmod | grep '^algif_aead '

# Check if built into the kernel (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Empty lsmod output is not the all-clear it appears to be. On Debian, Ubuntu, and Arch-family distributions, algif_aead autoloads on demand – an unprivileged process can trigger the load simply by opening an AF_ALG socket with a matching algorithm name. On RHEL-family distributions, the code is compiled directly into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y) and never appears in lsmod regardless of state. Treat the host as exposed unless the kernel command line explicitly blacklists the AEAD initcall or the kernel is patched.

You are also not protected simply because your distribution hardens user namespaces. The Copy Fail trigger does not require creating a new namespace – the AF_ALG socket family is reachable directly from a standard unprivileged process on default installations.

What Copy Fail Is

Copy Fail is a local privilege escalation vulnerability in the Linux kernel crypto subsystem. The bug lives in the authencesn AEAD template – the authenticated-encryption mode used for IPsec ESN – and becomes exploitable when reached through AF_ALG together with splice(2).

The exploitable combination emerged from three changes made years apart, none of which was wrong on its own. The authencesn template, added in 2011 to handle IPsec ESP Extended Sequence Numbers, used the caller’s destination buffer as scratch space – harmless when only the kernel’s internal xfrm layer called it. AF_ALG later exposed AEAD operations to userspace. In 2017, a performance optimization removed an internal copy in the AEAD path, allowing the kernel to operate directly on the supplied memory page. The combination became dangerous when the data path originated from splice(2) against a file-backed page-cache page.

The discovery itself is part of why this bug matters. Theori researcher Taeyang Lee hypothesized that combining AF_ALG sockets with splice(2) might create an underexplored attack surface around scatterlist page provenance. Rather than auditing manually, the team fed that one-line hypothesis into Xint Code – their AI-assisted scanning system – pointed at crypto/. About an hour later, Copy Fail came back as the highest-severity finding. Additional high-severity bugs surfaced in the same scan are still working through coordinated disclosure.

The upstream fix is a direct revert of the original optimization commit (a664bf3d603d). That detail matters because it illustrates how these bugs often survive review: the optimization itself appeared correct in isolation, but adjacent execution paths were never modeled against it.

Why Copy Fail Is Different

This is the part worth paying attention to if you have followed the steady stream of Linux LPEs over the past decade – Dirty COW, Dirty Pipe, StackRot, Dirty Frag, and others in the same family.

Dirty Pipe mattered because it transformed page-cache corruption into a practical privilege-escalation primitive. Most bugs in this category, however, still carried operational friction. They were race-conditioned, kernel-version-specific, dependent on unusual modules, blocked by namespace restrictions, or unreliable enough that defenders could realistically buy time.

Copy Fail removes much of that friction.

The published exploit reportedly works with little or no modification across the major mainstream Linux distributions tested by the researchers. There is no large per-distro offset table or lengthy target-selection logic. The exploit path is unusually portable.

The exposure window is also unusually broad. The vulnerable optimization entered upstream Linux in 2017 and propagated into long-term-support kernels that remain inside vendor support windows today. That includes enterprise systems, embedded deployments, appliances, and frozen infrastructure that organizations often postpone upgrading for years.

Most importantly, exploitation is highly reliable. Many modern kernel LPEs involve probabilistic behavior – heap shaping, race timing, or complex chains involving multiple primitives. Copy Fail is comparatively straightforward. Attempts either succeed or fail cleanly without destabilizing the host.

The reachable attack surface is also unusually common. Unlike niche modules involved in some recent kernel exploits, algif_aead ships broadly across mainstream distributions and is either compiled in or autoloads on demand. Default installations across servers, desktops, and container hosts frequently expose a reachable path from an unprivileged process to the vulnerable code.

The result is that many traditional “buy time” assumptions do not help much here. In practice, meaningful risk reduction comes down to patching the kernel or removing access to the vulnerable path.

Why Modern Infrastructure Makes This Worse

“Local attacker” used to imply something relatively constrained – physical access, a stolen SSH credential, or a prior network compromise.

That definition no longer reflects how Linux infrastructure operates in 2026.

Modern infrastructure is built around shared execution. Kubernetes nodes co-host workloads from different namespaces. CI/CD runners execute pull-request code from external contributors. Cloud notebooks, developer sandboxes, multi-tenant SaaS platforms, and build systems routinely run partially trusted code on shared kernels.

In that environment, “local” increasingly resembles what “internet-facing” used to mean.

A malicious npm dependency landing in CI, a web application RCE that grants a low-privilege shell, a compromised developer account, or an incomplete container escape chain can all become stepping stones to full root access. Copy Fail compresses the distance between initial foothold and full kernel-level compromise.

The vulnerability is not remotely exploitable on its own. An attacker still needs code execution somewhere on the host. But in shared-execution environments, the supply of potential footholds is already large enough that the distinction matters less than it once did.

How the Exploit Actually Works

Linux exposes kernel crypto functionality to userspace through AF_ALG sockets. A process can request algorithms such as authencesn(hmac(sha256),cbc(aes)) and pass data through standard read/write interfaces.

The 2017 optimization attempted to improve performance by avoiding unnecessary internal copies during certain AEAD operations. Instead of copying input into temporary buffers and copying results back out, the kernel could sometimes operate directly on the supplied memory page.

That assumption breaks when the input originates through splice(2) from a file-backed descriptor. Unlike ordinary reads and writes, splice can transfer references to existing cached pages instead of copying data. The crypto path incorrectly treated those pages as writable scratch space and performed an in-place transformation against them.

The behavior is specific to authencesn. Other standard AEAD algorithms – GCM, CCM, regular authenc – confine their writes to the legitimate output area. The authencesn template, originally written for an internal IPsec code path that controlled both ends of the operation, treats the caller’s destination scatterlist as scratch space. When AF_ALG exposed that path to userspace and splice injected file-backed pages into it, the result was a primitive that writes 4 controlled bytes per operation into the page cache of any readable file.

Each operation actually fails – HMAC verification fails because the ciphertext is fabricated, and recvmsg() returns an error to the caller. The 4-byte write persists anyway. By repeating the operation across chosen offsets, an attacker plants shellcode into the cached image of a setuid binary such as /usr/bin/su.

The disk contents never change. The modification exists only in memory until the cached page is evicted. Filesystem integrity tools, file hashing, and disk forensics may therefore observe nothing unusual even though the cached executable image has been altered long enough for the attacker to execute it as root.

The public PoC follows a relatively short chain:

Open an AF_ALG socket bound to authencesn
Open a setuid binary such as /usr/bin/su for reading
Use splice to move the target’s cached pages into the AF_ALG path
Trigger the in-place crypto operation, which writes 4 attacker-chosen bytes per call
Repeat across offsets to plant shellcode in the cached image
Execute the modified cached binary as root

Reimplementations in C, Go, and on arm64 already exist alongside the original Python PoC. An older Python on the target is not a meaningful barrier. The original Xint/Theori write-up remains the best technical reference for defenders who need deeper implementation detail.

Mitigation

The safest remediation path is protecting the running kernel immediately. There are three practical ways to reduce exposure, listed here in order of speed and operational impact.

1. Rebootless patching (fastest, no downtime)

KernelCare released live patches for Copy Fail against supported running enterprise kernels before several downstream distributions shipped updated kernel package versions.

The rebootless patch neutralizes the exploit path on the running kernel without requiring an immediate reboot – reducing exposure immediately rather than waiting for the next maintenance cycle.

Some vulnerability scanners may temporarily continue reporting affected kernel versions even after rebootless patching because vendor package versions and scanner detection logic may lag behind the protected running kernel state.

For organizations managing uptime-sensitive infrastructure, this is the fastest path to remediation.

Not a KernelCare customer yet? New-customer pricing is discounted through the end of June. Learn more about KernelCare here.

2. Install a patched kernel and reboot

The standard remediation path is deploying the vendor-supplied patched kernel package and rebooting affected systems.

Organizations should validate patch availability for their distribution and prioritize environments where partially trusted code can execute – including Kubernetes nodes, CI/CD runners, shared hosts, developer infrastructure, and multi-tenant application platforms.

3. Temporary manual mitigation (if patching must wait)

If neither live patching nor immediate reboot windows are available, the AF_ALG AEAD attack surface can be temporarily disabled through the kernel command line.

Read this first: the mitigations below remove the AF_ALG AEAD attack surface. Most workloads degrade gracefully – dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS, and SSH do not depend on it. Applications explicitly using the OpenSSL afalg engine, hardware crypto offload via AF_ALG, or direct AEAD socket binding may fail or lose performance. Validate before broad deployment.

First, determine how algif_aead is shipped on your kernel:

# Loadable module (Debian, Ubuntu, Arch family)

grep -qE '^algif_aead ' /proc/modules && echo "loaded as module" || echo "not currently loaded"

# Built-in (RHEL, AlmaLinux, Rocky, CentOS Stream, Oracle Linux, CloudLinux)

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

If the config grep returns =y, the code is compiled into the kernel. Modprobe blacklists and rmmod will silently appear to succeed but provide no protection.

Universal mitigation (works on both module and built-in kernels) – disable the initcall via the kernel command line:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

sudo reboot

After reboot, verify:

grep -o 'initcall_blacklist=algif_aead_init' /proc/cmdline

Empty output means the parameter did not take – recheck grubby and confirm a real reboot occurred.

Loadable-module-only mitigation (Debian, Ubuntu, Arch and similar) – useful when a reboot must be deferred:

sudo sh -c 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif_aead.conf'

sudo rmmod algif_aead 2>/dev/null || true

Confirm:

grep -qE '^algif_aead ' /proc/modules && echo "still loaded" || echo "not loaded"

Do not rely on this approach on RHEL-family hosts. Both commands return success regardless of whether the system is built-in, producing a false sense of protection.

If exploitation is suspected, evict cached pages so modified executable pages reload from disk:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

This is containment, not remediation. If an attacker already obtained root access, persistence mechanisms may already exist elsewhere on the system.

SELinux and AppArmor can technically block AF_ALG socket creation, but only when configured to deny it for unconfined or broadly-permitted processes. Default policies on every major distribution allow it. Treat MAC-based restriction as a hardening measure for fleet-wide rollouts, not a same-day mitigation.

For Kubernetes operators, OVHcloud published a DaemonSet mitigation approach for managed clusters. The same pattern can apply broadly across Kubernetes environments where coordinated reboots are difficult during emergency response windows.

If AF_ALG cannot be disabled because workloads depend on it, the remaining options are isolating untrusted local execution or rebootless-patching the kernel until maintenance windows become available.

For KernelCare Enterprise users, rebootless patches for Copy Fail were released against existing supported enterprise kernels before several downstream distributions published updated kernel package versions.

As a result, some scanners may temporarily continue reporting vulnerable kernel versions even when the running kernel has already been protected through rebootless patching. Updated vendor kernel builds and matching detection logic are expected to follow.

Detection

There is no reliable post-compromise detection signature for Copy Fail.

Successful exploitation leaves no on-disk artifact, the syscall pattern resembles legitimate userspace crypto activity, and the cached modifications disappear once pages are evicted.

In most environments, retrospective confirmation will be difficult unless syscall telemetry, eBPF instrumentation, or detailed audit logging was already enabled before exploitation occurred.

The most useful signals to monitor include:

Unexpected algif_aead module loads on systems without known AF_ALG consumers
Unusual execution of su or sudo shortly after AF_ALG activity
splice(2) operations targeting AF_ALG sockets from file-backed descriptors

Detection rules keyed to Python execution patterns will miss other implementations – C, Go, and arm64 reimplementations of the exploit are public and require no Python on the target. These are heuristics, not guarantees. Any system where untrusted users had shell access during the exposure window should be treated as potentially compromised.

Prioritized Remediation Checklist

Apply a rebootless patch or deploy a patched kernel immediately. KernelCare Enterprise users can neutralize the exploit path on supported running kernels without rebooting. Otherwise, install the vendor-patched kernel package and reboot affected systems.
If patching must wait, apply the initcall_blacklist=algif_aead_init kernel-command-line mitigation after validating workload impact. The modprobe-based workaround circulating in some early advisories does not work on RHEL-family kernels.
Review environments where partially trusted code can execute – CI systems, shared hosts, Kubernetes nodes, developer infrastructure, and SaaS worker fleets.
Hunt for suspicious AF_ALG activity beginning from disclosure on April 29 onward.
Reboot patched systems to flush vulnerable runtime state and cached pages.

Why This Class of Bug Keeps Coming Back

Copy Fail, Dirty Pipe, and Dirty Frag differ in implementation details but share the same underlying pattern: performance-oriented fast paths making incorrect assumptions about memory ownership.

In each case, a write operation reached a page the kernel incorrectly believed was safe to modify.

The page cache repeatedly becomes the victim because it is intentionally shared. Every process reading a file observes the same underlying physical page. A single unintended write into that shared page can become visible to privileged binaries loading executable code from it.

The solution is not simply “stop optimizing.” Modern systems depend on these performance paths. Nor is permanently disabling whichever module happened to be involved in the latest exploit a long-term answer.

The deeper fix involves enforcing stronger page ownership guarantees throughout kernel memory handling paths – work that upstream maintainers have already begun, but which progresses slowly because it affects some of the kernel’s most performance-sensitive subsystems.

Copy Fail will likely not be the last vulnerability in this family.

And Linux may only represent the visible portion of the problem.

Copy Fail survived nearly a decade inside heavily reviewed open-source code, then was surfaced in about an hour by an AI-assisted scanner with a single operator prompt. Linux is the part of the stack that gets scanned because it can be scanned – openly, by anyone. The far larger surface of proprietary firmware, vendor kernels, legacy protocols, and chip microcode has historically depended on the assumption that hidden code meant hidden bugs. As Igor Seletskiy argues in Open Source is the Tip of the Iceberg, that assumption is now expiring. Copy Fail is one of the early data points; it will not be one of the last.