Copy Fail Linux kernel flaw lets local users gain root on major distributions

A newly disclosed Linux kernel vulnerability called Copy Fail can let an unprivileged local user gain root access on affected systems. The flaw is tracked as CVE-2026-31431 and has a CVSS 3.1 score of 7.8, which places it in the high-severity range.

The vulnerability affects the Linux kernel’s algif_aead crypto interface and can be triggered through AF_ALG sockets combined with the splice() system call. Researchers say the bug can corrupt the page cache of readable files and turn that corruption into root access.

This is not a remote vulnerability by itself. An attacker first needs local access, a compromised account, a container foothold, or code execution through another weakness. Once that foothold exists, Copy Fail can become a fast path to root.

At a glance

Item	Details
Vulnerability	CVE-2026-31431
Name	Copy Fail
Severity	High, CVSS 7.8
Bug type	Linux kernel local privilege escalation
Affected component	algif_aead, AF_ALG userspace crypto API
Attack requirement	Local access or code execution on the target system
Public PoC	Available

Why Copy Fail is serious

Copy Fail is dangerous because it does not depend on a fragile race condition or a complex timing trick. Researchers described it as a straight-line logic bug that works reliably on tested systems.

The public proof of concept is also small. Xint Code said a 732-byte Python script using standard library modules was enough to gain root on tested distributions, including Ubuntu, Amazon Linux, RHEL, and SUSE.

The flaw also creates a detection problem. The exploit corrupts the in-memory page cache, while the file on disk remains unchanged. That means basic file integrity tools that compare disk checksums may not catch the tampering.

How the kernel bug works

The bug traces back to a 2017 optimization in the Linux kernel’s AEAD crypto handling. That change allowed certain cryptographic operations to work in-place, where source and destination buffers overlap.

When a file is moved through splice() into an AF_ALG socket, the kernel can reference page cache pages directly instead of copying the file data. Under the vulnerable path, those page cache pages can end up in a writable destination scatterlist.

The authencesn crypto template then performs a small scratch write. Researchers found that this write can land inside a page-cache-backed file, giving an attacker a controlled four-byte write into memory.

What attackers can do with it

• Corrupt the page cache of a readable setuid binary.
• Modify the in-memory version of a privileged file without changing it on disk.
• Run the corrupted in-memory binary to gain root privileges.
• Bypass simple checksum-based file integrity checks.
• Use a container foothold as a possible path toward host compromise.

The most common example involves a setuid binary such as su. An attacker corrupts the cached version, executes it, and obtains a root shell.

The impact becomes more serious in shared systems. Multi-user servers, CI/CD runners, build hosts, Kubernetes nodes, and container platforms should receive priority because one low-privilege workload can lead to wider compromise.

Affected systems and tested distributions

Distribution tested by researchers	Kernel version listed in reports
Ubuntu 24.04 LTS	6.17.0-1007-aws
Amazon Linux 2023	6.18.8-9.213.amzn2023
RHEL 10.1	6.12.0-124.45.1.el10_1
SUSE 16	6.12.0-160000.9-default

The vulnerability affects kernels that include the vulnerable algif_aead behavior introduced in 2017. Downstream Linux distributions may have backported affected code into long-term support kernels, so administrators should check vendor security trackers instead of relying only on the visible kernel version.

Ubuntu lists CVE-2026-31431 as high priority and describes the issue as a trivial local privilege escalation. Other vendors are also tracking the bug and releasing or preparing fixed kernels.

Patch and mitigation guidance

The upstream Linux fix reverts algif_aead to out-of-place operation. This removes the risky in-place handling that allowed page cache pages to become part of a writable destination path.

Administrators should apply kernel updates from their Linux distribution as soon as available, then reboot into the patched kernel. Live patching may help in some environments, but teams should confirm coverage with their vendor.

If a patched kernel is not available yet, CERT-EU recommends disabling the algif_aead module as an interim mitigation. This reduces exposure to the vulnerable crypto interface.

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

Extra protection for containers and Kubernetes

Copy Fail matters in containerized environments because containers share the host kernel. If a container can access the affected AF_ALG path, it may become a route toward host-level compromise.

Organizations should prioritize Kubernetes nodes, shared container hosts, and CI/CD runners that execute untrusted code. These systems often run workloads from many users or projects on the same kernel.

Security teams can also restrict AF_ALG socket creation through seccomp, AppArmor, SELinux, or other workload controls where possible. This should support patching, not replace it.

Detection steps for defenders

• Monitor unexpected AF_ALG socket creation from non-crypto tools.
• Look for Python processes that launch shells and privileged setuid utilities.
• Watch for process chains involving Python, sh, su, sudo, passwd, mount, or newgrp.
• Review container workloads that can access AF_ALG sockets.
• Check whether algif_aead is loaded on exposed multi-user systems.
• Confirm that patched kernels are active after reboot, not only installed.

Detection will not be simple because the exploit uses legitimate system calls. Runtime monitoring can help, but patching remains the main defense.

Teams should also review root-level activity on systems where untrusted users had shell access. The exploit may leave fewer file-based artifacts than normal tampering because the disk copy of the target file may stay unchanged.

Why admins should not delay

Public exploit code changes the risk level. Attackers do not need to rediscover the bug, and defenders should expect the exploit to appear quickly in privilege escalation playbooks.

The first priority should be internet-facing servers where a web vulnerability could give attackers a low-privilege shell. The next priority should be shared development systems, hosting platforms, research clusters, and container hosts.

Even though Copy Fail needs local execution, many real attacks start with low-level access. This flaw gives attackers a way to turn that limited access into full system control.

FAQ