Host Deep Dive #1 — Copy Fail (CVE-2026-31431): how a kernel copy bug can lead to root

“Copy Fail” is the name given to CVE-2026-31431, a privilege escalation vulnerability in the Linux kernel.

Put simply, it lets an unprivileged process trick the kernel into temporarily changing a file's contents in memory. The file on disk can remain untouched, while other processes end up seeing the modified version in the cache.

Under certain conditions, an attacker can use this behavior to change the code of a privileged program and turn execution as an ordinary user into execution as root.

The vulnerability was introduced in 2017, during development of Linux kernel 4.14, and remained in various kernel versions and distributions for about nine years. It was fixed in 2026, with patches also made available for several maintained kernel branches.

Because the flaw is in the kernel itself, it isn't limited to one distribution. Linux systems such as Ubuntu, Debian, Red Hat, SUSE, and Amazon Linux may be vulnerable if they run an affected kernel that hasn't been patched.

The vulnerability was discovered by Taeyang Lee, a researcher at security company Theori. It was publicly disclosed on April 29, 2026.

Where the bug lives

The vulnerability is in AF_ALG, a Linux interface that lets programs use cryptographic operations implemented by the kernel.

Think of AF_ALG as a way for an application to say:

“Kernel, run this cryptographic operation for me.”

The affected code is in the algif_aead module.

The problem arises in the path used to move data for that operation. Under certain conditions, a write intended for a specific buffer can end up reaching pages that belong to the page cache.

So what is the page cache?

It's an area of RAM that Linux uses to temporarily hold file data.

For example, when a program reads file.txt, the kernel may load that file's contents into memory:

DISK
  │
  │ read file
  ▼
┌──────────────┐
│  PAGE CACHE  │
│     RAM      │
└──────┬───────┘
       │
       ▼
    program

If another process needs to read the same file, the kernel can reuse the data already in RAM instead of reading it from disk again.

That's the mechanism Copy Fail takes advantage of.

Why the file “changes” without a write to disk

This is one of the key details of the vulnerability.

Imagine we have a file on disk:

DISK
/usr/bin/program
[ original contents ]

The kernel may hold a page from that file in the page cache:

RAM
PAGE CACHE
[ original contents ]

With Copy Fail, that page in memory can be modified:

DISK
[ original contents ]

RAM
PAGE CACHE
[ MODIFIED contents ]

The file on disk doesn't have to change.

The problem is that the kernel may keep using that page in memory to serve subsequent reads.

A process can therefore ask to read /usr/bin/program and receive whatever is currently in the page cache, even if it differs from the contents stored on disk.

It's as though there are temporarily two versions of the same file:

           DISK
             │
             │ original contents
             ▼
       ┌─────────────┐
       │    FILE     │
       └─────────────┘

             RAM
             │
             │ modified contents
             ▼
       ┌─────────────┐
       │ PAGE CACHE  │
       └─────────────┘

That gap between what's on disk and what the kernel holds in memory is central to understanding Copy Fail.

How this becomes privilege escalation

So far, all we have is a change to data in memory.

To turn that into privilege escalation, the attacker needs to reach a file that serves a particular purpose.

One possible target is a setuid executable.

On Linux, an ordinary user can run a setuid program, but the resulting process can start with the privileges of the file's owner.

When that owner is root, the flow looks something like this:

ordinary user
      │
      ▼
setuid program
      │
      ▼
process with root privileges

Normally, the user can't change that program's code.

Copy Fail creates a different situation:

ordinary user
      │
      ▼
exploits the flaw
      │
      ▼
modifies a page in the page cache
      │
      ▼
privileged program
      │
      ▼
runs the modified contents
      │
      ▼
elevated privileges

The key point is that the attacker doesn't necessarily need to modify the file on disk.

Instead, they take advantage of the fact that the program may be loaded from a page that has already been changed in memory.

That's how a small amount of memory corruption can have a much larger impact.

Why this is local privilege escalation

Copy Fail isn't a remote code execution vulnerability.

On its own, it doesn't let someone on the internet send a request to a server and become root.

The scenario is closer to this:

1. attacker gains code execution
              │
              ▼
2. code runs as an ordinary user
              │
              ▼
3. attacker exploits Copy Fail
              │
              ▼
4. manipulates the page cache
              │
              ▼
5. gains elevated privileges

In other words, the attacker generally needs some way to execute code on the machine already.

That could come from a compromised account, a vulnerable application, or another component that allows code execution.

Copy Fail is the second step: moving from a context with limited privileges to a privileged one.

Why AF_ALG matters

AF_ALG is a socket interface for accessing the Linux kernel's cryptographic functionality.

A program can open this type of socket and use cryptographic operations without implementing the entire operation in userspace.

Here's the simplified flow:

Application
    │
    │ AF_ALG
    ▼
Linux kernel
    │
    ▼
Cryptographic subsystem

Copy Fail occurs in one of the internal paths used by this interface.

The vulnerable code is associated with the algif_aead module.

An unprivileged process that can reach the vulnerable path can exploit the faulty copy operation.

What makes Copy Fail interesting

At first glance, the flaw seems fairly small:

a copy operation
        ↓
a page of memory
        ↓
a few bytes changed

But that page may hold part of a file that another process trusts.

The chain can then become:

kernel bug
     ↓
page cache modified
     ↓
file contents differ in memory
     ↓
another process reads the modified contents
     ↓
privileged code is affected
     ↓
privilege escalation

That's why seemingly minor kernel bugs can have serious consequences.

How to test it

The public disclosure is available at copy.fail.

To study the behavior, use an isolated, disposable lab environment, such as a virtual machine created specifically for testing.

Keep in mind that you don't need to reproduce the exploit to check whether a system is protected.

Start by checking the kernel version and installing the security updates provided by your distribution.

How to protect your systems

The main fix is to update the Linux kernel to a version that includes the patch for CVE-2026-31431.

In Docker environments, there are also specific mitigations to prevent containers from reaching the vulnerable path. Docker has published its own fixes and recommendations for the issue.

The approach looks like this:

               FIX
                │
                ▼
         Patched kernel
                │
                +
                │
           MITIGATIONS
                │
                ▼
       Docker / seccomp /
       AppArmor / SELinux

Patching the kernel is the primary measure. Isolation mitigations provide an additional layer of defense.

Putting it all together

An unprivileged process exploits a kernel flaw to temporarily modify the in-memory contents of a file held in the page cache.

If a privileged process uses that file, the modification can lead to privilege escalation.

Here's the core idea:

AF_ALG
  │
  ▼
kernel bug
  │
  ▼
page cache modified
  │
  ▼
file contents changed in RAM
  │
  ▼
privileged process
  │
  ▼
privilege escalation

The crucial detail is that an attacker doesn't necessarily need to change a file on disk to change what another process reads. The vulnerability targets the copy the kernel keeps in memory.

Find Copy Fail on your hosts with runtz

Scan all your hosts now. Get started at runtz.dev.