CVE-2026-31431: “Copy Fail” — Critical Linux Kernel Vulnerability Lets Local Users Gain Root in Seconds

CVE-2026-31431: “Copy Fail” – Critical Linux Kernel Vulnerability Lets Local Users Gain Root in Seconds

On April 29, 2026, a critical vulnerability in the Linux kernel, tracked as CVE-2026-31431 and nicknamed “Copy Fail,” was publicly disclosed. This high-severity local privilege escalation vulnerability affects virtually every Linux distribution released since 2017, allowing unprivileged local users to gain root access within seconds using a mere 732-byte proof-of-concept exploit. With working exploits available for major enterprise distributions including Ubuntu, Amazon Linux, RHEL, and SUSE, this vulnerability represents an immediate and severe threat to unpatched Linux systems worldwide.

What is CVE-2026-31431?

CVE-2026-31431 is a local privilege escalation (LPE) vulnerability in the Linux kernel’s algif_aead module, which is part of the kernel’s userspace crypto API (AF_ALG). The vulnerability has a CVSS score of 7.8 and was introduced in 2017 through commit 72548b093ee3, which implemented an optimization for AEAD (Authenticated Encryption with Associated Data) operations to use in-place processing.

The flaw allows an unprivileged local user to corrupt the page cache backing setuid binaries such as /usr/bin/su and /usr/bin/sudo, effectively bypassing file permissions and gaining root privileges. The exploit chain is reliable, race-free, and works across different Linux distributions without requiring any kernel modules or system modifications.

Technical Mechanism: How Copy Fail Works

The “Copy Fail” vulnerability operates through a complex but straightforward chain of operations that exploit the interaction between three kernel components:

1. AF_ALG Socket Binding: The attacker creates an AF_ALG socket bound to the authencesn(hmac(sha256),cbc(aes)) algorithm, which is available in default kernel configurations.
2. Page Cache Splicing: Using the splice() system call, the attacker maps the page cache of a target setuid binary (typically /usr/bin/su) into the crypto pipeline.
3. Controlled Memory Corruption: By sending a specially crafted recvmsg() call, the attacker causes a 4-byte write at a specific offset within the target file’s cached data in memory, effectively patching the binary with shellcode.

Unlike previous Linux kernel vulnerabilities like Dirty Pipe (CVE-2022-0847), which required precise timing and version-specific targeting, Copy Fail operates as a straight-line logic flaw that triggers reliably across distributions. The HMAC verification fails as expected, but the memory corruption persists in the page cache, allowing the attacker to stage shellcode into the cached binary and execute it with elevated privileges.

Affected Systems and Distributions

The vulnerability affects Linux kernels from version 4.14 through 7.0-rc, with specific regression points affecting the 6.18.x and 6.19.x release series. Fixed versions include 7.0, 6.19.12, and 6.18.22.

Directly Confirmed Affected Distributions:

Additional distributions running kernels in the affected range include Debian, Arch Linux, Fedora, Rocky Linux, AlmaLinux, Oracle Linux, and various embedded Linux distributions. Ubuntu 26.04 (Resolute) and later kernels are not affected by this vulnerability.

Impact Assessment

The impact of CVE-2026-31431 is severe due to several factors:

• Universal Applicability: The vulnerability affects virtually all Linux distributions released since 2017, encompassing billions of systems worldwide.
• Low Complexity Exploitation: The public proof-of-concept is only 732 bytes of Python code, making exploitation trivial for attackers.
• Immediate Root Access: Successful exploitation grants root privileges within seconds, bypassing all security controls.
• No Authentication Required: The vulnerability only requires local access, which can be achieved through various attack vectors including web application compromises, phishing, or malware.
• Persistent Impact: Even after system reboot, the corrupted page cache can continue to provide root access until the system is properly patched.

Organizations with unpatched Linux systems face significant risks including complete system compromise, data exfiltration, lateral movement within networks, and persistent backdoors. The vulnerability is particularly dangerous in cloud environments, container orchestration platforms, and multi-tenant systems where local access can lead to broader infrastructure compromise.

Detection Methods

Several detection approaches are available to identify potential exploitation attempts of CVE-2026-31431:

Runtime Detection with Falco

The open-source Falco security tool can detect suspicious AF_ALG socket creation patterns using the following rule:

- rule: Unexpected Process Using Kernel AEAD Crypto Socket
  condition: >
    evt.type = socket and
    evt.rawres >= 0 and
    (evt.arg.domain contains AF_ALG or evt.rawarg.domain = 38) and
    (evt.arg.type = 5 or evt.arg.type = 2053) and
    not proc.name in (cryptsetup, "systemd-cryptsetup", veritysetup, integritysetup, "cryptsetup-resh", kcapi-enc, kcapi-dgst, kcapi-rng, kcapi-sym)
  output: Unexpected process %proc.name opened AF_ALG AEAD kernel crypto socket
  priority: CRITICAL
  tags: [host, container, kernel, cve, CVE-2026-31431]

System Monitoring

Monitor for the following suspicious activities:

• Creation of AF_ALG sockets by non-cryptographic processes
• Unexpected modifications to setuid binaries
• Sudden privilege transitions following kernel crypto syscalls
• Processes accessing /usr/bin/su or other setuid binaries without legitimate reasons

File Integrity Monitoring

Implement file integrity monitoring on critical setuid binaries to detect unauthorized modifications, particularly after kernel crypto operations.

Immediate Mitigation Strategies

While vendor patches are being prepared, organizations should implement the following mitigation measures:

Temporary Module Disablement

Disable the algif_aead kernel module persistently on all affected systems:

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

This workaround does not affect essential cryptographic operations including:

• dm-crypt/LUKS encryption
• Kernel TLS (kTLS)
• IPsec/XFRM
• OpenSSL, GnuTLS, NSS operations
• SSH connections

Applications that may be affected are those explicitly configured to use the afalg engine or that bind aead/skcipher/hash sockets directly. Exposure can be assessed with:

lsof | grep AF_ALG

Container Environment Hardening

Implement seccomp profiles to block AF_ALG socket creation in containerized environments:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "action": "SCMP_ACT_ERRNO",
      "args": [],
      "comment": "Block AF_ALG socket creation",
      "includeSyscall": "socket",
      "name": "socket",
      "args": [
        {
          "index": 0,
          "op": "SCMP_CMP_EQ",
          "value": "38"  // AF_ALG constant
        }
      ]
    }
  ]
}

Access Control Restrictions

Implement strict access controls to limit local user privileges on critical systems, especially those running containers, Kubernetes nodes, or CI/CD pipelines that may process untrusted workloads.

Patching Recommendations

Once vendor patches become available, organizations should prioritize systems based on risk exposure:

High Priority Systems

1. Kubernetes Control Plane and Worker Nodes: Container orchestration platforms are particularly vulnerable due to multi-tenant workloads.
2. CI/CD Pipeline Systems: Build and deployment systems that process untrusted code or configurations are at high risk.
3. Multi-Tenant Cloud Environments: Shared infrastructure where local access could lead to tenant compromise.
4. Development and Testing Systems: Systems with multiple users or untrusted code execution.

Patch Implementation Process

1. Test First: Validate patches in non-production environments before deployment.
2. Schedule Maintenance Windows: Plan kernel updates during scheduled maintenance periods.
3. Monitor for Issues: Watch for regressions or compatibility problems after patching.
4. Document Changes: Maintain detailed records of patch deployments and any observed issues.

Post-Patch Verification

After applying patches, verify the mitigation by:

• Confirming kernel version meets minimum requirements (7.0, 6.19.12, or 6.18.22)
• Checking that algif_aead module is no longer loaded
• Running vulnerability scanners to confirm resolution
• Monitoring security logs for any residual suspicious activity

Frequently Asked Questions

Q1: Does this vulnerability affect cloud providers like AWS, Azure, or GCP?

A: Yes, if you’re running any Linux instances with kernels in the affected range (4.14 through 7.0-rc), your systems are vulnerable. Cloud providers will need to release updated AMIs and container images. You should check with your specific cloud provider for their patch status timeline and apply mitigations until patches are available.

Q2: Will disabling the algif_aead module break my applications?

A: In most cases, no. The algif_aead module is primarily used for userspace cryptographic operations, and most applications use alternative interfaces like OpenSSL or kernel TLS. However, applications that explicitly use the AF_ALG interface with AEAD algorithms may be affected. You should assess your environment using lsof | grep AF_ALG to identify any impacted applications before applying the workaround.

Q3: How can I detect if this vulnerability has been exploited on my systems?

A: Look for several indicators: unexpected root shell processes originating from unprivileged users, modifications to setuid binaries that don’t match file checksums, or suspicious processes that were recently modified. Use the provided Falco rules to detect AF_ALG socket creation patterns. You can also compare file checksums of critical binaries against known good values, and audit system logs for unusual privilege escalation attempts.

Q4: Do container runtime security solutions provide protection against this vulnerability?

A: Yes, if properly configured. Container runtime security solutions that implement seccomp profiles can block AF_ALG socket creation at the container level. Additionally, runtimes that implement proper user namespace mapping and privilege dropping can mitigate the impact of successful exploitation. However, these controls should be combined with kernel patching for comprehensive protection.

Q5: Is there a way to test my systems for this vulnerability without risk of exploitation?

A: Yes, you can use vulnerability scanning tools that check kernel versions against the affected ranges. Some security vendors have released specific detection signatures for CVE-2026-31431. You can also verify your kernel version against the fixed ranges (7.0, 6.19.12, 6.18.22) and check if the algif_aead module is loaded on your system. The PoC exploit should only be used in controlled testing environments.

Q6: What should I do if I cannot patch immediately?

A: Implement the temporary mitigations immediately: disable the algif_aead module and implement seccomp profiles to block AF_ALG socket creation. Additionally, restrict local access to affected systems, implement strict user controls, and monitor for suspicious activity. Consider isolating high-risk systems in separate network segments and preparing incident response plans in case exploitation occurs.

Future Implications and Broader Concerns

The “Copy Fail” vulnerability highlights several concerning trends in Linux kernel security:

• Long-lived Vulnerabilities: The flaw existed in the kernel for nearly nine years before being discovered, demonstrating how performance optimizations can introduce security risks that persist for extended periods.
• Universal Impact: The vulnerability affects virtually all major Linux distributions, indicating the need for more rigorous testing of kernel changes across different environments.
• Exploit Simplicity: The small size and simplicity of the exploit demonstrate how kernel vulnerabilities can be easily weaponized by attackers.

This incident underscores the importance of:

• Regular security reviews of kernel changes and performance optimizations
• Enhanced testing procedures for new kernel features
• More rapid patch coordination across Linux distributions
• Stronger runtime security controls to detect exploitation attempts

References

• Original Disclosure: Theori – “Copy Fail: 732 Bytes to Root on Every Major Linux Distribution” – https://xint.io/blog/copy-fail-linux-distributions
• Sysdig Technical Analysis: “CVE-2026-31431: ‘Copy Fail’ Linux kernel flaw lets local users gain root in seconds” – https://www.sysdig.com/blog/cve-2026-31431-copy-fail-linux-kernel-flaw-lets-local-users-gain-root-in-seconds
• CERT-EU Security Advisory: “High Vulnerability in the Linux Kernel (‘Copy Fail’)” – https://cert.europa.eu/publications/security-advisories/2026-005/
• NVD Entry: CVE-2026-31431 – https://nvd.nist.gov/vuln/detail/CVE-2026-31431
• Red Hat Security Bulletin: RHSB-2026-02 – Cryptographic Subsystem Privilege Escalation – https://access.redhat.com/security/vulnerabilities/RHSB-2026-02
• Proof of Concept: Theori – https://github.com/theori-io/copy-fail-CVE-2026-31431
• Linux Kernel Fix: Mainline commit reverting the 2017 optimization – https://github.com/torvalds/linux/commit/fafe0fa2995a

This article provides comprehensive guidance on understanding, detecting, mitigating, and ultimately resolving the critical CVE-2026-31431 “Copy Fail” vulnerability. Organizations should treat this as an urgent security priority and take immediate action to protect their Linux systems.