Copy Fail: The 732-Byte Python Script That Roots Every Major Linux Distro

Researchers at Xint published a privilege escalation exploit on April 29 that should make every Linux server admin uncomfortable. The bug has been in the kernel since 2017. The exploit is 732 bytes of Python using nothing but the standard library. The same script runs unchanged on Ubuntu, Amazon Linux 2023, RHEL 10.1, and SUSE 16. It leaves nothing on disk.

They called it Copy Fail. The name comes from how the vulnerability works: a logic error in how the kernel handles in-place cryptographic operations lets an unprivileged user write 4 controlled bytes into the page cache of any file they can read. That's enough to overwrite a setuid binary in memory and get root.

Where the Bug Lives

The flaw is in algif_aead.c, part of the AF_ALG kernel interface that exposes hardware-accelerated cryptography to userspace. It's not a component most people think about. In 2017, a performance optimization was added to avoid copying data when doing in-place AEAD operations. The optimization chained tag pages directly into a writable scatterlist using sg_chain(). The problem: when pages from splice() ended up in that writable path, they brought along page cache pages from the read side of the file.

The result is a 4-byte write primitive into the page cache of any file the attacker can read. The kernel doesn't check whether those pages should be writable. It doesn't mark the modified memory as dirty. From the filesystem's perspective, nothing changed.

Standard Library. No Race Condition. No Offsets.

The Xint researchers published the exploit alongside the disclosure. It's 732 bytes of Python, using os, socket, and zlib. The only requirement beyond Python 3.10 is the os.splice syscall wrapper added in that version. No third-party packages. No kernel version fingerprinting. No timing-dependent race condition to win.

The attack path is deterministic:

The Visibility Problem Is the Real Story

Most privilege escalation exploits leave traces. They drop a binary, modify a config file, or abuse a SUID wrapper that shows up in audit logs. Copy Fail does none of that.

Because the kernel never marks the modified pages as dirty, write-back to disk never happens. The file on disk is byte-for-byte identical to before the attack. File integrity monitoring tools like AIDE, Tripwire, or auditd watching for file changes see nothing. The modification exists only in memory. When the system reboots, it's gone — but by then the attacker has already established persistence through other means.

This matters for incident response as much as it matters for detection. If you're investigating a compromised Linux host and looking for modified files, you may not find any. The initial access might leave no artifact that a post-incident forensic analysis would catch.

Affected Systems

The bug was introduced in 2017 and is present in any unpatched Linux kernel from that point forward. The same 732-byte Python script demonstrates root on:

• Ubuntu 22.04 LTS and 24.04 LTS
• Amazon Linux 2023
• Red Hat Enterprise Linux 10.1
• SUSE Linux Enterprise 16

Microsoft's security blog confirmed impact across major cloud provider environments, noting that most Linux workloads in Azure, AWS, and GCP share this kernel heritage. The researchers explicitly tested cloud-deployed instances, not just on-premises VMs.

Python 3.10 or later is required for the os.splice wrapper. Any modern Linux distribution ships with Python 3.10+, so this is not a meaningful barrier.

Patches and Status

Kernel patches are available. Canonical published fixes for Ubuntu 22.04 and 24.04 on May 1. RHEL and SUSE patches followed within 48 hours. Amazon Linux 2023 patches were pushed to the package repository the same day as the Xint disclosure.

The fix is in algif_aead.c: the 2017 in-place optimization is removed, and splice paths through the AEAD interface now go through a copy buffer rather than directly into the scatterlist. Performance impact is negligible for most workloads.

What to Do

This is a straightforward patch-and-verify situation. There's no workaround short of disabling the AF_ALG interface, which would break applications using kernel crypto acceleration.

• Patch now. If your Linux fleet has a patching cadence, this warrants an exception. The exploit is public, the script is 732 bytes, and it requires zero special setup.
• Audit container environments first. The container escape angle elevates risk significantly for Kubernetes clusters. Compromised pods that can reach node-level credentials are a serious lateral movement path.
• Review Python version in CI/CD. If your build pipelines or test environments run Python 3.10+ on Linux — and most do — they are in scope. A compromised dependency or malicious package could bundle this exploit as a secondary payload.
• Don't rely on FIM for detection. If you were counting on file integrity monitoring to catch this class of attack, Copy Fail demonstrates why that's insufficient. Runtime kernel integrity tools (like falco or eBPF-based monitors watching AF_ALG socket activity) catch this; static file monitors don't.

The deeper takeaway is how long this sat unnoticed. Nine years in a kernel crypto interface that's part of nearly every Linux distribution. The attack surface in the Linux kernel is large, the code is old, and performance optimizations made in good faith can introduce exploitable paths that don't look dangerous until someone maps the full control flow.