Vulnerability at a Glance

Background: What Is the AF_ALG Socket Interface

To understand Copy Fail, it helps to understand why the AF_ALG socket interface exists and what role it plays in the kernel. Linux exposes hardware-accelerated cryptographic operations to userspace through a standard socket family called AF_ALG (address family 38). Instead of requiring applications to perform encryption entirely in userspace, AF_ALG allows a process to hand data to the kernel and receive the cryptographic result back - taking advantage of CPU or hardware crypto acceleration where available.

The interface operates through a two-step setup. First, a process calls socket(AF_ALG, SOCK_SEQPACKET, 0) and binds it to a named algorithm, providing parameters like the cipher suite, key material, and IV. It then calls accept() to receive an operation file descriptor. Subsequent sendmsg() and recvmsg() calls on that operation descriptor trigger the actual cryptographic work.

A critical capability of this interface is support for splice operations. The splice() system call can transfer data between two file descriptors without copying it through userspace. Critically, one of those file descriptors can be a regular file - and when it is, the data being transferred comes directly from kernel page cache, the kernel's shared in-memory buffer for file-backed data. This zero-copy pathway is where Copy Fail creates its opportunity.

The 2017 Commit That Started It All

In 2017, a performance optimization was merged into the Linux kernel for the algif_aead module (commit 72548b093ee3). The change was straightforward in intent: during AEAD (Authenticated Encryption with Associated Data) operations, instead of maintaining separate source and destination scatterlists, the optimization collapsed them into a single combined scatterlist that both req->src and req->dst pointed to simultaneously.

This meant the AEAD implementation would process data in place - reading from and writing to the same memory region. For most AEAD algorithm implementations, this causes no problem. The read completes before any write begins, and the fact that src and dst share the same backing memory is inconsequential.

The authencesn algorithm is different. During its AEAD operation, authencesn uses the destination buffer as a scratch pad before it has finished consuming the source input. When req->src and req->dst both point to the same scatterlist, this scratch write contaminates the data mid-operation. The algorithm writes into the destination region while that same memory is still being read as input. The result is a 4-byte write at an attacker-influenced offset into whatever memory backs the destination scatterlist.

Step-by-Step: How the Exploit Path Works

# Step 1: Open an AF_ALG socket - no capabilities required
socket(AF_ALG=38, SOCK_SEQPACKET=5, 0)

# Step 2: Bind to the vulnerable AEAD algorithm
bind(fd, {alg_type='aead', alg_name='authencesn(hmac(sha256),cbc(aes))'})

# Step 3: Accept an operation file descriptor
op_fd = accept(fd)

# Step 4: Open the target setuid binary - page cache gets populated
suid_fd = open("/usr/bin/su", O_RDONLY)

# Step 5: Splice page cache pages into the AEAD op fd (zero-copy)
splice(suid_fd, NULL, op_fd, NULL, PAGE_SIZE, 0)
     └── page cache pages of /usr/bin/su now in the writable dst scatterlist

# Step 6: Trigger the AEAD operation
sendmsg / recvmsg
     └── authencesn uses dst as scratch pad
     └── 4-byte write lands in page cache of /usr/bin/su
     └── in-memory binary is now corrupted - disk file unchanged

# Step 7: Repeat ~40 iterations across different page offsets
     └── delivers sufficient corruption to redirect setuid execution

# Step 8: Execute the corrupted setuid binary
exec("/usr/bin/su")
     └── root shell spawned

Why File Integrity Monitoring Cannot See This

One of the most operationally significant properties of Copy Fail is its relationship with file integrity monitoring. Tools like Tripwire, AIDE, and similar FIM solutions work by recording cryptographic hashes of files on disk and alerting when those hashes change. They compare what is stored on disk against a known-good baseline.

Copy Fail never touches the disk. The authencesn scratch write lands in page cache - the kernel's in-memory read buffer for file-backed data. The on-disk bytes of /usr/bin/su remain exactly as they were before exploitation. An sha256sum of the file produces the correct, expected hash. AIDE reports no changes. Tripwire reports no changes. Any audit mechanism that compares inode metadata, file size, timestamps, or disk-level checksums sees nothing.

The modification exists only in the kernel's page cache, a shared in-memory structure with no direct on-disk counterpart. It persists until memory pressure forces eviction or the system reboots. During that window, every process on the system that executes the targeted setuid binary invokes the corrupted in-memory version.

Affected Distributions and Scope

Copy Fail affects any Linux kernel built after commit 72548b093ee3 landed in mainline in 2017 and before the April 2026 vendor patches were applied. That window covers essentially every mainstream Linux distribution that shipped kernel packages between 2017 and April 29, 2026.

How Copy Fail Compares to Previous Linux LPEs

Linux local privilege escalation vulnerabilities are not unusual, but Copy Fail's operational characteristics separate it from its predecessors. The two most comparable high-profile Linux LPEs are Dirty Cow (CVE-2016-5195) and Dirty Pipe (CVE-2022-0847), both of which involved manipulation of page cache or copy-on-write mechanisms. The comparison matters because it clarifies exactly what makes Copy Fail a different class of threat.

SafeBreach researchers confirmed that the same unmodified 732-byte script produced root shells across Ubuntu, RHEL, Amazon Linux, SUSE, and Arch Linux. No recompilation, no kernel version detection, no per-distro offset tables. This cross-distro reliability means an attacker with local access to any Linux host can immediately attempt privilege escalation without knowing the distribution, kernel version, or installed toolset in advance - a qualitative shift from what previous LPEs required.

What Is Coming in This Series