Linux Privilege Escalation (CVE-2026-31431): Copy Fail Exploit and Detection

Overview

Not every privilege escalation comes from a broken piece of code. In some cases, combining normal kernel features in the wrong way is enough to get root. “Copy Fail” is one of those cases.

Copy Fail (CVE-2026-31431) was disclosed on April 29, 2026, with a CVSS score of 7.8. is a highly reliable Linux local privilege escalation vulnerability that has remained exploitable across nearly all mainstream distributions since 2017. Unlike traditional kernel exploits, it does not rely on race conditions or kernel-specific offsets, but instead leverages a deterministic logic flaw to overwrite page cache memory and execute arbitrary code as root. The Proof of concept code is already publicly avaialble and easy to run.

At a high level, the technique allows a low-privileged user to tamper with trusted SUID (Set User ID) binaries and execute them with elevated privileges.

As of this blog writing, there are no confirmed real-world attacks yet, and it hasn’t been widely adopted by ransomware or botnets so far. That said, the barrier to entry is low. The exploit is simple, works across multiple kernel versions, and does not require much tuning, which makes it a practical candidate for real-world use.

CVSS & Impact Summary

Affected Systems

All Linux distributions running kernels released since 2017 are affected.The impacted distributions and kernel versions are based on the findings published in the original Copy.Fail research blog.

Source: Copy.Fail

How the attack works

For detail understanding visit the original research blog but here is the summarize version of it

Technically, the exploit relies on the interaction between the AF_ALG kernel crypto interface and splice() syscall.

• splice() allows data to be transferred directly between things like files, pipes, and sockets without a traditional read/write cycle.
• AF_ALG is a kernel crypto interface exposed through sockets, normally used for things like hashing or encryption.

The public proof-of-concept starts by opening a SUID binary such as /usr/bin/su, although any SUID-root binary can be targeted. The attacker then creates an AF_ALG socket, which is normally used to access kernel cryptographic functions, and sets up a pipe to move data between file descriptors.

The exploit uses splice() to transfer data directly between the file, the pipe, and the AF_ALG socket. Since splice() performs zero-copy transfers, the data does not pass through user space in the usual way.

The key detail is where this data ends up. By chaining these operations with the AF_ALG interface, controlled data is written into the page cache backing the target SUID binary. The file on disk remains unchanged, but its in-memory representation is modified.

Technically, the exploit relies on the interaction between the AF_ALG kernel crypto interface and splice() syscall.

• splice() allows data to be transferred directly between things like files, pipes, and sockets without a traditional read/write cycle.
• AF_ALG is a kernel crypto interface exposed through sockets, normally used for things like hashing or encryption.

The public proof-of-concept starts by opening a SUID binary such as /usr/bin/su, although any SUID-root binary can be targeted. The attacker then creates an AF_ALG socket, which is normally used to access kernel cryptographic functions, and sets up a pipe to move data between file descriptors.

The exploit uses splice() to transfer data directly between the file, the pipe, and the AF_ALG socket. Since splice() performs zero-copy transfers, the data does not pass through user space in the usual way.

The key detail is where this data ends up. By chaining these operations with the AF_ALG interface, controlled data is written into the page cache backing the target SUID binary. The file on disk remains unchanged, but its in-memory representation is modified.

When the binary is executed, the kernel serves it from the page cache rather than disk. As a result, the modified version runs with SUID privileges, allowing the attacker to gain root access.

This approach avoids typical indicators such as file writes, permission changes, or dropped binaries, since the entire modification happens in memory.

Detection for Copy Fail with Guardsix SIEM

Required Log Sources

• Unix Default Logs
  • Kernel Logs
• Auditd
• Unix Sysmon

Detection Strategy

The exploit itself is fairly minimal, but the behavior it triggers follows a clear pattern:

1. Initial payload execution (commonly via Python from publicly available PoCs)

2. Creation of an AF_ALG socket

3. Repeated use of splice() for data movement

4. Execution of a SUID binary in a root context

Each of these steps leaves a different trace depending on the available log source. Individually, they may not be suspicious, but together they form a strong signal.

Detection with Sysmon

In the public exploit code, the payload is executed through Python, which eventually spawns a shell and invokes a SUID binary.

This behavior can be captured by looking for shell processes spawned from Python that execute privileged binaries:

label="Process" label=Create    
"parent_process"="*python*"
"process" IN ["*/dash","*/bash","*/zsh","*/sh"] command="*su*"
| chart count() by user,host,"process",command

While the default PoC targets /usr/bin/su, the same technique can be applied to any SUID binary. To broaden detection coverage:

label="Process" label=Create     
"parent_process"="*python*"  
"process" IN ["*/dash","*/bash","*/zsh","*/sh"] command IN ["*su", "*sudo", "*passwd",
"*chsh", "*mount", "*umount","*pkexec", "*newgrp", "*crontab"]

Detection with Auditd

For environments relying on auditd, visibility comes from tracking the core primitives used by the exploit.

To enable this, syscall monitoring must include splice() and AF_ALG socket creation:

-a always,exit -F arch=b64 -S splice -k copyfail_splice
-a always,exit -F arch=b32 -S splice -k copyfail_splice
-a always,exit -F arch=b64 -S socket -F a0=38 -k copyfail_afalg
-a always,exit -F arch=b32 -S socket -F a0=38 -k copyfail_afalg
###Here, a0=38 corresponds to the AF_ALG address family.

A practical way to investigate is to follow the sequence of the exploit rather than relying on a single alert.

Start by identifying Python execution, then look for socket creation tied to AF_ALG, followed by splice() activity, and finally execution of a SUID binary in a root context.

The exploit begins by creating an AF_ALG socket and using it to send crafted data:

norm_id=Unix event_type="Syscall"
system_call=Socket  argument0=38

The heavy use of splice() is a core part of the technique, as it enables data movement without traditional write operations, so a high number of splice calls can be observed.

norm_id=Unix   event_type="SYSCALL" system_call=splice 

As the exploit completes, it results in the execution of a SUID binary with elevated privileges:

norm_id=Unix system_call=execve status_code=0 -user=root
command="*su*" effective_user=root

To account for variations in target binaries, analysts should include those binaries in the command filter.

norm_id=Unix system_call=execve status_code=0 -user=root
effective_user=root  command IN ["*su", "*sudo", "*passwd*",
"*chsh", "*mount", "*umount","*pkexec", "*newgrp", "*crontab"]

Detection with Default Unix Logs

Even in environments without auditd or Sysmon, partial visibility is still possible through kernel logs.

Detecting AF_ALG Activity

The exploit interacts with the kernel crypto subsystem, which can leave traces such as protocol registration:

norm_id=Unix "process"=kernel "Registered PF_ALG protocol family"  

Analysts can also look for a combination of kernel messages and unusual process execution behavior:

norm_id=Unix ("Registered PF_ALG protocol family"  
OR  "process 'su' launched '/bin/sh' with NULL argv: empty string added")

Remediation

The following mitigation steps are based on recommendations from the original Xint.io research on Copy Fail.

The most reliable fix is to patch the kernel. Updating to the latest kernel package provided by your distribution should include the necessary changes.

If applying updates is not immediately possible, there are a couple of temporary mitigation options.

You can restrict the use of AF_ALG by blocking socket creation through seccomp (secure computing mode), or disable the affected module entirely:

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

These workarounds are not a substitute for patching, but they can help reduce exposure until updates can be applied.