Copy Fail: A 732-Byte Script That Owns Your Linux Box

Published: at 09:38 AM

Not exactly a Saturday vibe, but while doing my usual check on one of our work VMs, something caught my attention this morning: a newly disclosed CVE that was not the usual “ah, that’s kind of interesting.” After a unique week with GitHub, the last thing I expected was a 9 year-old kernel-level privilege escalation lurking in our (well, almost everyone’s) infrastructure. But here we are.

It’s patched on at least one of the VMs now. Team debrief is coming. And this post is me thinking out loud so you don’t get blindsided the same way.

TABLE OF CONTENTS

Open TABLE OF CONTENTS

What Is Copy Fail?

CVE-2026-31431, nicknamed Copy Fail, is a logic bug in the Linux kernel’s authencesn cryptographic template, specifically the algif_aead interface exposed via AF_ALG sockets. It was publicly disclosed on April 29, 2026 by researchers at Theori, surfaced through Xint Code’s automated scanning of the Linux crypto/ subsystem..

The punchline? A 732-byte Python script is all it takes for any unprivileged local user to become root, as simple as that! No race conditions. No kernel offsets. No special configuration needed. Bi dardesar!

As Xint put it:

“A single 732-byte Python script can edit a setuid binary and obtain root on essentially all Linux distributions shipped since 2017.” — Xint Code, Copy Fail writeup

The Root Cause

This one goes back to 2017, when commit 72548b093ee3 added an in-place optimization to algif_aead.c. The optimization made req->src = req->dst during AEAD decryption and chained tag pages from the TX scatterlist into the RX buffer via sg_chain().

Here’s where it gets interesting. When userspace feeds the socket through splice(), those tag pages reference the page cache of the spliced file, not a private copy. authencesn’s decrypt path then writes 4 bytes into the tag region before the tag check returns -EBADMSG. The HMAC fails as expected, but the corruption in the page cache? That stays.

From the oss-security disclosure:

“This gives a local unprivileged attacker a controlled page-cache write primitive against any readable file… it can tamper with read-only or setuid executable content and may enable local privilege escalation or code execution until the page is evicted.”

In practice: repeat this at successive offsets to patch /usr/bin/su in memory, run su, get a root shell. واقعاً به همین سادگی - و مسخره‌گی.

Why It’s Particularly Nasty

Tenable’s FAQ puts the highest-risk environments clearly: cloud systems, container clusters, and CI/CD pipelines running untrusted code. If you’re running shared workloads or multi-tenant infrastructure, this is not a “patch it next sprint” situation.

What You Should Do

Immediate mitigation! disable the algif_aead module:

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

Permanent fix — update your kernel. Fixed versions upstream:

Check your distro’s security advisories / Ubuntu, Amazon Linux, and RHEL have all started shipping patches.

A Note on How It Was Found

What I found almost as interesting as the bug itself is how it was discovered. Theori’s writeup notes it was:

“Surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem — one operator prompt, no harnessing.” — Bugcrowd writeup on Copy Fail

An AI-assisted audit found a 9-year-old kernel bug in an hour. That’s the world we’re in now. As someone who has worked (and still works) close to the metal on infrastructure, this is both impressive and slightly unsettling.

Final Thoughts

Omarchy Repro

This week was kind of unique. Between the GitHub turbulence and now this. If you manage Linux servers (VMs, bare metal, containers, CI runners) treat this one seriously. The exploit is public, it’s reliable, and it leaves no trace. Patch now, talk to your team, and if you haven’t set up automated vulnerability monitoring on your VMs, let this be the nudge.

Down the Rabbit Hole