Copy.fail: The Linux Exploit That Works on Every

There's a new Linux vulnerability making the rounds, and it's the kind that makes security researchers go "wait, what?" It's called copy.fail, and if you've been running Linux since 2017—which, let's be real, is basically everyone—your system is vulnerable to local privilege escalation.

The wild part? It's a single 732-byte Python script that works on every single distribution of Linux. No distro-specific patches needed. No kernel version targeting. Just run it, and boom—root access.

What Makes This Different

Most privilege escalation exploits are finicky. They rely on specific timing windows, particular kernel offsets, or version-specific quirks. You need different exploits for Ubuntu vs. Fedora vs. Arch. Not this one.

Copy.fail is what's called a logic bug—a fundamental flaw in how the kernel handles certain operations. The Low Level channel's demonstration took about two hours of research to fully understand, and honestly, that tracks. This isn't your standard buffer overflow or race condition. It's a beautiful, terrible exploit that abuses Linux's cryptographic socket subsystem in a way that nobody saw coming.

"Copy.fail is a local privilege escalation," the presenter explains. "This is a vulnerability that requires you to have access on a computer already, but if you're there on any version of Linux since 2017, you could use this vulnerability to escalate up to root."

So yeah, if an attacker already has a foothold on your system—maybe through a compromised service account or a phishing attack—this is their golden ticket to complete control.

How It Actually Works

The exploit targets something called the AF_ALG socket, which is Linux's way of letting userspace programs access kernel-level cryptographic algorithms. This is actually a good feature in theory—you shouldn't roll your own crypto, and the kernel might have hardware acceleration that makes encryption faster.

Here's where it gets technical, but stay with me because the cleverness is worth it.

Linux sockets use scatter lists to track where data lives in memory—linked lists of pages, offsets, and lengths. When you send data through a socket, the kernel needs to know which physical memory pages contain your data. Input scatter lists track what you're sending; output scatter lists track what comes back.

The AF_ALG socket handles authenticated encryption with associated data (AEAD), which combines encryption with authentication. Think of it like sending a locked box where you also know who sent it. The kernel expects data in a specific order: authenticated data, encrypted payload, then authentication tags.

Normally, input scatter lists are read-only from the kernel's perspective. But back in 2017, someone made an optimization: for performance reasons, the kernel started using a reference to the tags page as the output location for crypto operations. The input and output scatter lists pointed to the same memory.

That optimization is the crack in the foundation.

The Splice Trick

The exploit uses a Linux system call called splice(), which pipes data from one file descriptor into another. Here's the clever bit: instead of sending all the required data through normal channels, the exploit sends the authenticated data and encrypted payload normally, then uses splice() to append a page from a completely different file—specifically, /usr/bin/su, the setuid binary that lets users switch to root.

"What splice allows you to do is take a pipe and pipe the data associated with a file descriptor and pipe it into a socket," the presenter explains. "What that allows you to do is take a page and append it to an input scatter list."

When the cryptographic algorithm runs, it writes temporary scratch data—just four bytes at a time—into what it thinks is its normal workspace. But because of the splice operation, those four bytes are actually being written into the cached memory page for /usr/bin/su.

The attacker can control exactly which offset those four bytes land at. Write at offset 0, then offset 4, then offset 8, gradually overwriting the entire binary in the kernel's page cache. Not on disk—just in memory.

When the exploit finally executes /usr/bin/su, the kernel doesn't reload it from disk. It already has a cached version in memory. Except that cached version is now shellcode. And because the kernel still sees it as the original setuid binary, it runs that shellcode as root.

Bada bing, bada boom—root access without entering a password.

What This Means for Real Systems

The demonstration showed this working on a system from March 27th, 2024. The vulnerability has been lurking since 2017. That's seven years of exposure.

To be clear: this is a local privilege escalation, not remote code execution. An attacker needs some level of access to your system first. But in the real world, that's not much of a barrier. Compromised credentials, vulnerable services, supply chain attacks—there are plenty of ways to get that initial foothold. Once someone's in, copy.fail hands them the keys to the kingdom.

The fix involves reverting the 2017 optimization that made input and output scatter lists share memory. There's a mainline kernel commit (A664B) that addresses it. If the AEAD module is compiled separately as a loadable kernel module, you can disable it entirely and prevent it from loading on boot.

But here's the thing about logic bugs: they don't show up in automated testing the same way memory corruption issues do. They're design flaws, not implementation mistakes. Someone had to think really hard about how these systems interact to find this.

That's both encouraging and terrifying. Encouraging because it means the exploit required genuine ingenuity. Terrifying because it means there might be other logic bugs hiding in plain sight, waiting for someone clever enough to connect the dots.

For now, patch your systems. Check your kernel versions. And maybe rethink your assumption that local privilege escalation is a minor concern. In a world where attackers move from initial compromise to full domain control in under an hour, every escalation path matters.

—Tyler Nakamura