Hey! I'm not the expert in crypto or reverse engineering just sharing the things that I learnt throughout from the articles and from the research that the others peoples have did..
Hey hackers,
I'm a passionate cybersecurity enthusiast and ethical hacker. I love solving CTFs on TryHackMe and Hack The Box, while also diving into recently discovered vulnerabilities to enhance my skills.
Let's understand the story;
Think of it like a library photocopier:
Imagine a library. Books on shelves = files on your Linux system. When you want to read a book, the library makes a quick photocopy and puts it on your desk — that's the page cache (a fast in-memory copy the kernel keeps).
The kernel never hands you the actual book. It hands you the desk copy. If someone scribbles on your desk copy, the book on the shelf is untouched — but YOU are now reading the scribbled version.
Copy Fail lets an attacker scribble on your desk copy of /usr/bin/su (or any program that gives root) — and the scribble gives them a root shell. The book on the shelf stays pristine. No alarms go off.
Two versions of every file exist at once:
Linux keeps two representations of files:
Disk (permanent) **/usr/bin/suactual bytes** ← never changed by this attack
Page cache (RAM) su copyin memory← this IS what gets executed
When you type su, the kernel reads from the page cache, not from disk. It trusts the page cache completely. This is by design — it makes Linux fast. Copy Fail abuses this trust.
Background — what is AF_ALG?
The door the attacker walks through;
Linux has a feature called AF_ALG — a way for normal (unprivileged) programs to ask the kernel to do cryptographic operations (encryption, hashing) on their behalf. This is totally normal and legitimate.
Think of it like a post-office window. You slide your letter through the slot (your data), the post office stamps it (does crypto), and slides it back. You never go "behind the counter" — you use the window.
The attack works by sliding a file (like /usr/bin/su) through this window using splice(), tricking the kernel into including the file's page cache pages inside its crypto workspace.
The bug — what goes wrong in 2017:
The "in-place optimization" mistake
In 2017, a developer made the crypto code faster by making it process data "in place" — meaning the input and output buffer are the same memory region. This saves a memory copy. Makes sense, right?
Input buffer = Output buffer ← same memory, 2017 optimization
The problem: when the attacker uses splice() to feed a file into the socket, the kernel chains the file's page cache pages onto that combined input/output buffer. The crypto algorithm then writes its scratch data — 4 bytes — into what it thinks is "output space." But those 4 bytes land inside the file's page cache.
su page cache chained into → crypto output← algorithm writes here
The attack — what the attacker actually does:
4 bytes is all it takes
The authencesn algorithm (used by IPsec VPN) writes exactly 4 bytes of scratch data at a specific offset. The attacker controls that offset by choosing the right input size.
su byte 0 su byte 1 su byte 2 XX XX XX XX su byte 7
4 red bytes overwritten in page cache. Disk copy: untouched.
By targeting 4 specific bytes in a setuid binary, the attacker can change a CPU instruction — for example, turning a "check if you are root" check into a "skip this check" instruction. Then when anyone runs su, it hands out a root shell.
The entire exploit is a 732-byte Python script. No race condition. Works first try, every time.
Why it's so stealthy:
It leaves no trace
Security tools that watch for file tampering (like file integrity monitors) check the bytes on disk. The disk bytes never changed. So they see nothing wrong.
md5sum /usr/bin/su abc123... (clean) — same before and after attack
The corruption lives only in RAM. A reboot wipes it — the page cache reloads from the clean disk file. Until the reboot, every user on the system who runs su gets a root shell.
It also crosses container boundaries — because containers on the same host share the kernel's page cache. One container compromised = the whole host at risk.
The fix and mitigation
How to stop it:
The patch simply reverts the 2017 in-place optimization. The crypto code goes back to using separate input and output buffers — slower by a tiny amount, but safe.
The temporary workaround is to blacklist the algif_aead kernel module. This closes the "post-office window" that the attack uses. It does NOT affect disk encryption (LUKS), SSH, OpenSSL, or IPsec itself — only applications that explicitly use the AF_ALG userspace crypto socket interface.
Run this to block the attack immediately on an unpatched system:
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.confsudo rmmod algif_aeadThen update your kernel as soon as your distro releases the patched version.
A normal user can open a crypto socket, pipe the kernel's in-memory copy of a program like su into it, and the kernel's own crypto code accidentally scribbles 4 bytes into that copy — changing a security check to "always pass" — so the next person who runs su gets a root shell, and the actual file on disk is never touched.
That's it. No hacking, no exploit kit, no race condition — just a 732-byte Python script exploiting a logic mistake that's been sitting in the kernel since 2017.
Thankyou For Reading:)