🐧 CVE-2026-31431 — CopyFail: Linux Kernel Privilege Escalation

Complete Case Study — How it was discovered, how it works, how to test, how to replicate (in a safe environment) and how to fix the critical vulnerability that affects almost all Linux distributions since 2017.

🚨 Legal Notice / Disclaimer

This repository is for strictly educational purposes. The information presented here is intended for security professionals, researchers, and cybersecurity students. Never use any technique described here on systems without explicit authorization. Misuse of this information may constitute a crime under Law No. 12,737/2012 (Carolina Dieckmann Law) and the Brazilian Internet Civil Rights Framework (Law No. 12,965/2014).

📌 Overview

🔍 How It Was Discovered

The CopyFail vulnerability was discovered by the security company Theori during analysis of Linux kernel code, specifically in the subsystem responsible for copying data between memory spaces.

Timeline

March/2026      → Theori researchers identify anomalous behavior in the kernel
March/2026      → Responsible disclosure to the kernel security team
~1 week later   → Upstream patch available on kernel.org
May/2026        → Proof-of-concept (PoC) code publicly released
05/01/2026      → Microsoft publishes technical analysis
05/04/2026      → CISA adds to KEV Catalog (Known Exploited Vulnerabilities)
05/15/2026      → Deadline for patching in US federal agencies

Why the name "CopyFail"?

The Linux kernel has internal routines responsible for copying data between different memory regions (userspace ↔ kernelspace). The flaw is named CopyFail because the affected component fails to copy certain data when it should. This corrupts sensitive data structures inside the kernel, opening an exploitation window for privilege escalation.

⚙️ How the Vulnerability Works

Technical Concept

The Linux kernel manages memory in two distinct spaces:

Userspace: where normal (user) processes operate, with restricted access
Kernelspace: privileged space, with full access to hardware and system data

┌─────────────────────────────────────┐
│           USERSPACE                 │
│   Attacker Process (uid=1000)       │
│   → calls malicious syscall         │
└────────────────┬────────────────────┘
                 │ syscall
                 ▼
┌─────────────────────────────────────┐
│           KERNELSPACE               │
│   Data copy routine                 │
│   → BUG: fails to copy metadata     │
│   → corrupts control structure      │
│   → attacker manipulates pointer    │
│   → executes code as root           │
└─────────────────────────────────────┘

Exploitation Mechanism

Trigger: The attacker (unprivileged local user) invokes a specific syscall that triggers the faulty copy routine
Corruption: The failure to copy data corrupts a kernel control structure (e.g., credentials struct or function pointer)
Control Flow Hijack: The attacker leverages the corruption to redirect kernel execution
Privilege Escalation: The attacker's process runs with uid=0 (root), gaining full control of the system

Simplified pseudocode of the bug

// VULNERABLE version (simplified, for educational purposes)
int kernel_copy_data(struct user_request *req) {
    struct kernel_buffer kbuf;
    
    // BUG: copies only part of the data, ignoring critical fields
    // Security fields (security_context) are not copied!
    memcpy(&kbuf.data, req->data, req->size);
    // → kbuf.security_context remains uninitialized (memory garbage)
    
    process_buffer(&kbuf); // uses corrupted data
    return 0;
}

// FIXED version
int kernel_copy_data(struct user_request *req) {
    struct kernel_buffer kbuf;
    
    // FIX: copies the entire struct, including security fields
    if (copy_from_user(&kbuf, req, sizeof(struct kernel_buffer)))
        return -EFAULT;
    
    process_buffer(&kbuf);
    return 0;
}

🎯 Affected Systems

⚠️ Any Linux distribution running kernel ≤ 7.0 released since 2017 is potentially vulnerable.

💥 Exploitation Scenarios

Scenario 1 — Direct Local Attack

An unprivileged user on a shared server (e.g., hosting environment, VPS) runs the exploit and obtains root.

Scenario 2 — Chaining with Remote Exploit (RCE → LPE)

Internet → [RCE via web vulnerability] → limited shell → [CopyFail] → root

According to Microsoft's analysis: the flaw can be chained with an exploit delivered over the internet (e.g., RCE in a web application), resulting in full server compromise.

A Linux user is tricked into opening a malicious link or attachment that triggers the exploit locally.

Scenario 4 — Supply Chain Attack

A malicious actor compromises an open source developer account and injects the exploit into widely distributed code.

Scenario 5 — Datacenter Compromise

A compromised cloud server can expose all VMs, containers, applications, and customer databases on the same infrastructure.

🧪 How to Test (Safe Lab)

⚠️ ONLY in a controlled and isolated environment — VM with no external network access!

Prerequisites

# Required tools
sudo apt install -y git build-essential libssl-dev bc flex bison

# Check current kernel version
uname -r

# Check if it falls within the vulnerable range (≤ 7.0)
# Example of vulnerable output: 6.8.0-51-generic

Setting up the test environment

# 1. Create an isolated VM (recommended: VirtualBox or QEMU)
# Use an Ubuntu 24.04 or Debian Bookworm ISO

# 2. Confirm the VM has NO access to production internet
# (use host-only network or isolated NAT)

# 3. Create an unprivileged user to simulate the attacker
sudo adduser testuser
su - testuser

# 4. Verify that testuser has no sudo
sudo whoami  # should return: "testuser is not in the sudoers file"

Checking if the system is vulnerable

# Verification script (does NOT exploit, only checks)
#!/bin/bash

KERNEL_VERSION=$(uname -r | cut -d. -f1,2)
MAJOR=$(echo $KERNEL_VERSION | cut -d. -f1)
MINOR=$(echo $KERNEL_VERSION | cut -d. -f2)

echo "[*] Detected kernel: $(uname -r)"

if [ "$MAJOR" -lt 7 ] || ([ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 0 ]); then
    echo "[!] POTENTIALLY VULNERABLE to CVE-2026-31431 (CopyFail)"
    echo "[!] Check whether the patch has been applied by your distribution vendor"
else
    echo "[+] Kernel version outside the affected range"
fi

# Check if the patch has been applied (via package changelogs)
apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i "CVE-2026-31431" && \
    echo "[+] CVE-2026-31431 patch found in changelog" || \
    echo "[?] Patch not detected in changelog — verify manually"

🔬 Replicating the Exploit (Controlled Environment)

🔒 This section is strictly educational. The code below is a simplified didactic representation of the attack vector — it is not the real exploit (which is not disclosed here for ethical reasons).

Conceptual structure of the exploit

#!/usr/bin/env python3
"""
CVE-2026-31431 (CopyFail) — Didactic Representation
Purpose: Offensive/defensive security education
DO NOT USE ON SYSTEMS WITHOUT AUTHORIZATION
"""

import ctypes
import os
import sys

def check_environment():
    """Checks whether we are in a lab environment"""
    kernel = os.uname().release
    print(f"[*] Kernel: {kernel}")
    print(f"[*] Current UID: {os.getuid()}")
    
    if os.getuid() == 0:
        print("[-] Already root. Exploit not needed.")
        sys.exit(0)

def demonstrate_concept():
    """
    Conceptual demonstration of the attack vector:
    
    1. Identify the vulnerable syscall
    2. Build a payload that triggers the incomplete copy
    3. Monitor memory corruption
    4. Redirect the flow to escalate privileges
    
    In a real exploit:
    - The attacker uses techniques such as heap spray or ROP chains
    - Abuses the window between the corruption and the use of the corrupted data
    - Overwrites process credentials (uid → 0)
    """
    print("[*] Concept: trigger the faulty copy routine")
    print("[*] Concept: monitor corruption of kernel_buffer struct")
    print("[*] Concept: execution flow redirection")
    print("[*] See: https://xint.io/blog/copy-fail-linux-distributions")

def main():
    check_environment()
    demonstrate_concept()
    print("\n[i] For full technical analysis, refer to:")
    print("    → https://xint.io/blog/copy-fail-linux-distributions")
    print("    → https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/")

if __name__ == "__main__":
    main()

Monitoring during tests

# In a separate terminal, monitor kernel logs
sudo dmesg -w | grep -E "(oops|panic|null pointer|exploit|cve)"

# Monitor system calls
sudo strace -e trace=all -p <PROCESS_PID>

# Check UID changes in real time
watch -n 0.5 'cat /proc/self/status | grep -E "^(Uid|Gid)"'

🛡️ How to Fix

1. Update the Kernel (Definitive Fix)

# Ubuntu / Debian
sudo apt update && sudo apt upgrade -y linux-image-generic
sudo reboot

# Verify version after reboot
uname -r

# Red Hat / CentOS / Amazon Linux
sudo dnf update -y kernel
sudo reboot

# SUSE
sudo zypper update -t package kernel-default
sudo reboot

2. Verify that the patch has been applied

# Check the changelog of the installed kernel
apt changelog linux-image-$(uname -r) | grep CVE-2026-31431

# Via Ubuntu CVE tracker
# https://ubuntu.com/security/CVE-2026-31431

# Via Red Hat CVE Database
# https://access.redhat.com/security/cve/CVE-2026-31431

3. Temporary mitigations (if you cannot update immediately)

# Limit execution of SUID binaries (reduces attack surface)
find / -perm -4000 -type f 2>/dev/null

# Enable auditing of suspicious syscalls
sudo auditctl -a always,exit -F arch=b64 -S all -k syscall_audit

# Monitor privilege escalation attempts
sudo apt install -y auditd
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/sudoers -p wa -k sudoers_changes

4. Additional hardening after patching

# Enable kernel protections
# /etc/sysctl.conf — add:
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.perf_event_paranoid = 3
kernel.unprivileged_bpf_disabled = 1
net.core.bpf_jit_harden = 2

# Apply
sudo sysctl -p

5. Incident response checklist

Identify all Linux systems with kernel ≤ 7.0
Prioritize servers exposed to the internet or in datacenters
Apply patches from each distribution (not just upstream)
Review authentication logs for suspicious escalations
Check for unauthorized SUID binaries
Check crontabs and services running as root
Notify the security team and management
Document and report if there is evidence of exploitation

🔎 Indicators of Compromise (IOCs)

# Signs of possible exploitation:

# 1. Common user processes running as root
ps aux | awk '$1 != "root" && $2 == "0"'

# 2. Newly created SUID binaries
find / -perm -4000 -newer /etc/passwd -type f 2>/dev/null

# 3. Suspicious entries in /etc/passwd
grep "uid=0" /etc/passwd

# 4. Kernel logs with corruption messages
dmesg | grep -iE "(oops|BUG:|corruption|cve)"

# 5. Unauthorized network connections
ss -tulnp | grep LISTEN

📚 Lessons Learned

For Security Teams

Patch Management is critical — The upstream patch was available in ~1 week, but distributions take longer to deliver. Monitor your vendors actively.
Defense in Depth — LPE alone is not enough; the attacker needs initial access. Control who has access to the system.
Vulnerability chaining — Isolated "low-risk" CVEs can become critical when combined. Assess risk in context, not just by the isolated CVSS.
Supply chain is a real vector — Widely used open source code can be an attack vector. Implement package integrity verification.
Kubernetes and containers are not immune — If the host kernel is vulnerable, containers running on it are also affected.

For Developers

Always copy complete structs — Never copy individual fields of kernel control structs without ensuring all critical fields are initialized.
Use copy_from_user() correctly — Kernel copy functions have specific semantics. Read the documentation before using them.
Security code review — Kernel changes need security-focused review, not just functionality.

For Managers

Kernel updates are a priority — They are not just "routine maintenance." Kernel vulnerabilities are often critical.
Asset inventory is essential — You cannot patch what you do not know you have. Keep an up-to-date inventory of Linux systems and their kernel versions.
Incident response plan — Have a playbook ready for critical vulnerabilities with aggressive deadlines (like CISA KEV).

📖 References

🤝 Contributing

Found something outdated or want to add a test scenario? Open an issue or PR!

Please respect the code of conduct: this repository is for education and defense — not for malicious activities.

📄 License

MIT License — use it to learn, teach, and defend systems. Never to attack.

"Knowing the attack is the first step toward building the defense."

⭐ If this case study was useful, leave a star on the repository!

CVE ID	CVE-2026-31431
Alias	CopyFail
Type	Local Privilege Escalation (LPE)
CVSS Score	8.8 (High) / potentially Critical in a chain
Component	Linux Kernel — data copy mechanism
Versions	Linux Kernel ≤ 7.0 (distributions since 2017)
Discovered by	Theori (security company)
Disclosed on	March 2026
Upstream patch	Available ~1 week after responsible disclosure
CISA Status	Listed as actively exploited — KEV Catalog
CISA Deadline	Federal agencies must patch by 05/15/2026

Red Hat Enterprise Linux	10.1	✅ Vulnerable
Ubuntu LTS	24.04	✅ Vulnerable
Amazon Linux	2023	✅ Vulnerable
SUSE Linux	16	✅ Vulnerable
Debian	Recent stable	✅ Vulnerable
Fedora	Recent	✅ Vulnerable
Kubernetes (nodes)	All on kernel ≤7.0	✅ Vulnerable

Estudo-de-Caso-CVE-2026-31431-CopyFail

Most Popular