Copy Fail is a trivially exploitable logic bug in Linux, reachable on all major distros released in the last 9 years. A small, portable python script gets root on all platforms.
Posted by pipewire@reddit | linux | View on Reddit | 305 comments
krumpfwylg@reddit
From https://www.cve.org/CVERecord?id=CVE-2026-31431 :
affected
unaffected
Emt-22@reddit
Yeah. Not much of a problem for most of people's home machines and i strongly suspect not a problem for companies' servers either, at least mostly.
ZorbaTHut@reddit
Out of the six Linux computers I maintain, all of them are vulnerable to this. You're overestimating normal kernel update speed.
primalbluewolf@reddit
...you're on Manjaro and using a kernel from before 7?
ZorbaTHut@reddit
I use my computer to work. I want it stable. I see no particular reason to jump to the latest version instantly.
Infinity-of-Thoughts@reddit
Then you run the LTS kernel.
Don_Equis@reddit
I use it for work and keeping it up to date is good for security. Nowadays most stuff is rolling release. So you either follow a distro with quick security patches or a rolling release one. You can pick your battle, but you can't just not update.
placebo_button@reddit
Most enterprise Linux is absolutely NOT rolling release. Bleeding edge != secure. Security patches get back ported to support LTS OS and kernels.
Don_Equis@reddit
Sorry, I worded that weird (I'm not native English). What I meant is that the tools, apps or whatever is used is for most people rolling release.
The exceptions are normally already established business servers and stuff like that, but for most end day users stuff is rolling release. Does this sound better to you?
I don't like that tough! I like stability and having any IDE, editor, cli tool, whatever, needing to be bleeding edge is a pain for me. But I feel kinda forced to that.
Dangerous-Report8517@reddit
No because that's also wrong. Arch and derivatives are popular among a group of highly active enthusiasts, but most end users of Linux use non-rolling releases, and the entire point of releases is that they ship a set of packages that themselves are pinned at major versions.
ZorbaTHut@reddit
I somewhat disagree with this, but even to the extent that it's true, nothing requires jumping to the latest major kernel release, security patches are still deployed for older versions.
Don_Equis@reddit
Oh, definitely. When I said that you either follow rolling release or one with security patches, I tried to cover stuff like RHEL where the kernel version might be old, but it is patched if necessary. The same might apply for many.
It is also not mandatory to use system libs too. That's something that wasn't true many years ago. While I personally prefer to use as many official packages as possible, today there's flatpak, docker or other tools that allows you to run tools anywhere with reasonable security guarantees.
I'm not trying to defend the rolling release distros above the others. Is more a "it happens and except for many specific usage, you need to either follow it or have a reasonable workaround".
ZorbaTHut@reddit
Fair 'nuff, yeah :)
I frankly think there's a big hole in distros in that almost none of them provide "we give you safe tested versions by default, but you can forcibly upgrade stuff with a click if you want to"; sort of counterintuitively, the deep centralization of Linux distributions consistently results in less user choice without a shitload of aggravation, compared to Windows where you just download the version you want and install it.
I'm on Manjaro in the hopes that it provides a happy medium between six-month-obsolete software and bleeding-edge. It's . . . not great at this. But I haven't found anything better.
Patient_Sink@reddit
Last time I was using Manjaro there weren't really much own package maintenance going on. They were just delaying packages from arch, held them for 2 weeks and still managed to ship broken stuff (that was already known to cause issues upstream). Stuff rarely got patches backported, instead they would just ship the newer version which was still supposed to undergo testing instead of patching the old version.
Since they also ship their own kernel versions I would be very sceptical at how quickly they'd patch something like this unless you run the unstable kernels. And at that point you're just running arch with a middleman and some cosmetic patches.
yawara25@reddit
Are you guys just upgrading for the sake of having a higher version number?
m4teri4lgirl@reddit
Are you running some super bespoke app stack with databases that costs thousands of dollars per second if they go down? No? Are you running windows? No? Then update your shit.
yawara25@reddit
I am running windows, actually. Anyway this patch is getting backported to the older, stable kernel versions.
m4teri4lgirl@reddit
Then why are you even commenting
yawara25@reddit
Because I had a question.
m4teri4lgirl@reddit
No, you had a dumb ass comment to make about software updates.
yawara25@reddit
I don't know why you're getting so angry about this. It's not that serious.
m4teri4lgirl@reddit
I'm not angry, your belief that updating your system is unnecessary is in fact a dumb ass comment.
yawara25@reddit
That's not what I said at all. Security patches can be applied to older kernel versions, as many major distros do. You should be applying these security patches, or installing the updated packages (which won't necessarily be a newer kernel version).
m4teri4lgirl@reddit
Is this your comment?
https://www.reddit.com/r/linux/comments/1sz96iq/copy_fail_is_a_trivially_exploitable_logic_bug_in/oj1jsk1/
yawara25@reddit
Yes, feel free to go ahead and read it.
m4teri4lgirl@reddit
I don't see the word security mentioned at all. Was I supposed to read your mind? Or was it just a dumb ass comment?
Yamatocanyon@reddit
On my windows machines I always make sure to enable the slider to make sure I get updates as soon as they are available. I'm not waiting in line like the other plebs.
primalbluewolf@reddit
I mean pretty much, I don't need the new scheduler. The NTSYNC stuff is supposed to be a performance boost for wine, though.
Emt-22@reddit
Yep. Mentioned in the edit.
Shevizzle@reddit
https://knowyourmeme.com/photos/2243370-btw-i-use-arch
Emt-22@reddit
Yes i know i know... LOL
Infinity-of-Thoughts@reddit
Tbh, it's really the Fedora users that are worse at this point.
Linux_Account@reddit
Is there a sub for screenshots of elaborate, "I'm on Arch, by the way," comments?
Emt-22@reddit
At this point I'm honestly considering the deletion of my probably most upvoted comment of all time cuz people just come here to shit on me for accidentally telling I chose the distro that best fits me. And the choice was almost purely made based on the availability of packages. I used the install script to keep it simple and easy for me but still faced issues cuz the package repos didn't work as expected.
No one would give a shit if I told about "the supremacy of Debian" or some shit like that.
amaurea@reddit
Come on, they're just poking good-hearted fun at you, it's surely not meant as bullying.
IAmRoot@reddit
Supercomputer admins must be freaking out right now, though.
jrcomputing@reddit
HPC engineer here, we disabled all of our front end machines... And it's finals next week.
amaurea@reddit
The big cluster I work on is affected, and they haven't done or said anything.
IAmRoot@reddit
About what I expected, but I hadn't even considered the timing. I worked in HPC for 10 years and recently moved to embedded, though still optimizing math libraries. It's not even the current threat, either, but having to audit if anyone had used the exploit before it was publicly known, especially for classified systems.
analyticheir@reddit
They are. Thanks.
placebo_button@reddit
No they aren't lol
throwaway234f32423df@reddit
Ubuntu 24.04 is affected, made sure I had all currently available security patches applies but looks like they haven't patched this yet.
jenks@reddit
That kernel is currently 6.17.0-22-generic. I hope it gets replaced with a new, patched kernel soon.
DragonSlayerC@reddit
Ubuntu LTS's stick with old kernel versions for a long time, so that kinda expected. They have to patch in the fix themselves manually instead of just getting the patch by virtue of pulling the latest kernel sources.
placebo_button@reddit
Stop conflating "old" with LTS Linux/kernel versions. I can't stand seeing that trope repeated around here. Anything LTS that's still in support will get necessary security patches just like everything else out there.
The_frozen_one@reddit
Stop conflating “old” with something derogatory or negative, it’s just a relative designation. We don’t have to talk like marketers.
Dangerous-Report8517@reddit
Old does imply not actively updated though, which is exactly the misconception they're addressing
Fun-Badger3724@reddit
I prefer 'marketeers'. Makes them sound like they're mouseketeers!
levir@reddit
Makes me think of privateer, which seems apt.
cgaWolf@reddit
Yeah, but that makes them sound cool :(
Fun-Badger3724@reddit
makes them sound like a mickey mouse outfit in my head
hungarian_notation@reddit
Ubuntu 24.04 is what default WSL is on too, and it is vulnerable.
alexeyr@reddit
WSL issue: https://github.com/microsoft/WSL/issues/40365
Emt-22@reddit
Shit. Just got myself uwubuntu for a live usb this very day to have graphical software for partitioning and other stuff for my main machine. I'll maybe convert it from BIOS to UEFI for fastboot etc. We'll see.
throwaway234f32423df@reddit
they'll probably have it patched by tomorrow, and it's only exploitable if the attacker already has shell access, so for most people there's probably just nothing to panic over, just check again in a day or so and verify the fix was applied
Emt-22@reddit
Oh, of course. Forgot what I had edited into my own message. You're right. And as I said, I'm also not gonna install the ubuntu on any machine so it's even less of a problem. Will update it and do the UEFI conversion hopefully soon too. Too tired to read/write atm so will go catch some Z's in a minute.
themrjava@reddit
I'm curious on why you tough most companies were running arch lol.
McDonaldsWitchcraft@reddit
in their defense, you don't need to have a rolling distro to be safe from this. fedora and all of its derivatives are unaffected. it's just ubuntu/deb based that are usually stuck with old kernels.
Dangerous-Report8517@reddit
Most rpm based systems are stuck with old kernels too, since RHEL and co also use LTS kernels
Emt-22@reddit
I mean yeah I technically said so but you know damn well what I actually meant (which is that they have a new-ish kernel version but didn't know what distro has what version). XD
JackSpyder@reddit
Nice subtle arch user drop.
Particular-Poem-7085@reddit
nice observation about us arch users(which logically includes me btw!)
Ikinoki@reddit
Yeah it's a problem because now any rce is root exploit, not contained
OffbeatDrizzle@reddit
yeah that guy thinks that "well I can already get root on my own machine, what's the problem?"
the problem is that ANY application could theoretically have root access ENTIRELY without your knowledge
OffbeatDrizzle@reddit
I run fedora btw
RedSquirrelFtw@reddit
I guess it could be an issue for shared hosting that also provide SSH access. Although now days I would be reluctant to provide that and rather ask the clients what they want to do with SSH (ex: script offsite backups) and just implement that in the web UI.
stas-prze@reddit
Yeah, seedbox providers are going to scramble to update their systems, since most of them give you ssh access. My provider runs 5.10.0-39. Given their prior history with out-of-date kernels, I imagine anyone will just be able to run the PoC and get people's data out, some of which might be private. I'm considering reporting it to their support staff.
hungarian_notation@reddit
AFAIK all vanilla WSL installations are currently on Ubuntu 24.04, which is vulnerable to this.
mrdeworde@reddit
Masterful edit-inserted "I run Arch btw" there. No notes.
juipeltje@reddit
What about lts though?
krumpfwylg@reddit
Afaik, latest revisions of LTS kernels have all been patched.
Infiniti_151@reddit
How were 6.18. through 6.19.12 were affected again if 6.18.22 through 6.18. were unaffected? Did they remove the patch and added it back in 6.19.12?
natermer@reddit
Because those kernels were patched.
The Linux kernel mailing list post is a lot easier to understand.
https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/#u
This exploit was made known the Linux kernel community and distributions for some time and a lot of people already have patched kernels... if they are remembering to install updates.
Infiniti_151@reddit
Thanks. That makes sense
gmes78@reddit
6.19.0 was not released after 6.18.22.
DullPop5197@reddit
Well, my red had 5.0 box is good… it’s on kernel 2.0
intelminer@reddit
Good luck I'm behind a Cobalt Qube!
MooseBoys@reddit
TBF 4.14 was an LTS release - a lot of purpose-built boards likely built against it and never updated. That said, those kinds of devices are unlikely to accept arbitrary python code.
wpm@reddit
I wish they didn't minify the script itself so they can brag that it was only 732-bytes. It'd be much easier to see exactly what is going on and trying to compare the write up to the actual script is harder now too.
middlenameray@reddit
here's a readable version: https://github.com/rootsecdev/cve_2026_31431
make sure to pass the
--shelloption to make it actually exec a shellWorth_Trust_3825@reddit
would be great if each flag was explained what it does. This is the first time i'm reading about AF_ALG socket interface.
amroamroamro@reddit
PS: this proof-of-concept have the same idea, but implements a different payload
the original script overwrites /usr/bin/su binary in-memory, this one overwrites /etc/password file in memory
Realistic-Set1700@reddit
Yes and I also wonder why they used python 3.10 and still call the script portable. If I want to test the exploit on old systems from 2017 it is almost impossible to run the script. AF_ALG does not even work with older python3.
Here is a more portable exploit in C (static build with nolibc)
https://github.com/tgies/copy-fail-c
Fenguepay@reddit
https://github.com/desultory/CVE-2026-31431/blob/main/copyfun.py
i made a simple readable version here
aliendude5300@reddit
That is definitely more readable.
amroamroamro@reddit
i asked gpt to help read the script
it matches the steps explained in the writeup:
it starts by opening the socket and sending it crafted messages taking advantage of the vulnerability to overwrite the in-memory cached copy of
/usr/bin/su. then runssunow the payload overwriting the binary is encoded, let's decode:
the output hex:
7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 02 00 3e 00 01 00 00 00 78 00 40 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 38 00 01 00 00 00 00 00 00 00 01 00 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 9e 00 00 00 00 00 00 00 9e 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 31 c0 31 ff b0 69 0f 05 48 8d 3d 0f 00 00 00 31 f6 6a 3b 58 99 0f 05 31 ff 6a 3c 58 0f 05 2f 62 69 6e 2f 73 68 00 00 00
it's basically what overwrites the .text section of
su, everything before 31 c0 is ELF headers we can ignore, everything after is the actual logic, using an online dissassembler we get:again with gpt help, this corresponds to this C code (the injected shellcode):
struct_iovec@reddit
Probably to hide the fact that the exploit isn't that special to begin with
fellipec@reddit
Well... it works
JockstrapCummies@reddit
I'm curious why this bug is publicly published when distros don't have the time to push a fix first.
Seems like irresponsible disclosure.
DFS_0019287@reddit
See the timeline. https://copy.fail/#timeline
They did use responsible disclosure.
Zenkibou@reddit
They only contacted the kernel maintainers, but no distribution maintainer.
https://www.kernel.org/doc/html/v4.14/admin-guide/security-bugs.html#coordination says to contact linux-distros at vs.openwall.org which they apparently didn't do.
DFS_0019287@reddit
Ah, OK. I was not aware of that. Hmm, then the disclosure wasn't responsible.
DontBuyAwards@reddit
That doesn’t say it was disclosed to distros. It was reported to upstream, which is famously terrible at communicating security fixes. According to https://docs.kernel.org/process/security-bugs.html#coordination-with-other-groups, the reporter is supposed to let distros know by contacting the linux-distros mailing list. It’s not clear if this was done.
JockstrapCummies@reddit
That's really concerning. I can't imagine how Ubuntu, Debian, and RedHat all just collectively sat on it like this.
p-x-i@reddit
I restored using
$ sudo apt install --reinstall util-linux
then verified using
$ sudo debsums -s
did i missing anything?
LinuxSBC-Anna@reddit
You don't need to do that. Just reboot. The on-disk binary didn't change, just the page cache.
HolmesToYourWatson@reddit
Here's the console output formatted:
UnluckyDouble@reddit
Wait, does that mean immutable distros are immune since su is on a read-only volume? Or does it get the kernel to ignore its own restrictions?
Dangerous-Report8517@reddit
Immutable distros allow a lot of ephemeral stuff to happen, plus you could modify the image in the other volume, so I wouldn't rely on the immutability in and of itself as a security feature
Zenkibou@reddit
A RO volume still has a page cache, so it would still work recently the same way
chamcha__slayer@reddit
Didnt work on Arch, it showed the su login prompt. Also didnt work on my homelab system running dietpi.
larikang@reddit
I think it just got patched. Tried the exploit and it worked,
pacman -Syu, and it didn't work after.Dangerous-Report8517@reddit
Nah, I've got systems last updated a week or more ago that are running patched kernels
bipolarrogue@reddit
Does it require /usr/bin/su?→
No. Any setuid-root binary readable by the user works. passwd, chsh, chfn, mount, sudo, pkexec are all viable. The PoC defaults to su because it's present on every distro tested.
DFS_0019287@reddit
Seems to be suid binaries should not be world-readable. Just out of an abundance of precaution, I would think that permissions of -r-s--x--x would be safest for suid binaries.
DFS_0019287@reddit
Further discussion reveals this doesn't help. You can get root by mucking with /etc/passwd and that has to be world readable. So... yeah, fix the kernel or use one of the other mitigations.
blamedrop@reddit
Share
uname -routputs. Maybe you're on already patched kernels:affected
unaffected
DragonSlayerC@reddit
So my 6.19.14 kernel is safe. Nice.
rebbsitor@reddit
Sweet, my ancient WSL instance isn't affected! lol
chamcha__slayer@reddit
Yep, I am running unaffected kernels
6.18.22-current-rockchip646.19.14-arch1-1`
AeskulS@reddit
Tried running it in an alpine docker container. It also didnt work, only showing the su prompt
thkim1011@reddit
Docker uses your hosts kernel unless otherwise specified so you wouldn’t see any different behavior
AeskulS@reddit
Makes sense. Host is Arch, so that tracks
fellipec@reddit
Nice, your systems are patched.
ronchaine@reddit
On what system did you get this to work? It completely failed on every system I ran it on, and that included Ubuntu 24.04 with 6.17.0 kernel.
NotFromSkane@reddit
Ah, that's why it's not working for me. Thank goodness for immutable nix packages. (Also I don't have a /bin/usr/su, but I tried replacing that with /run/wrappers/bin/su)
monocasa@reddit
It doesn't overwrite on disk; it only corrupts the page cache.
xplosm@reddit
Which means unpatched immutable distros are also at risk.
Orio_n@reddit
No it won't. Do you know what a page cache is lol?
enp2s0@reddit
It doesnt rewrite su, just changes it in the page cache. The actual on-disk file remains read-only.
itscalledboredom@reddit
i don't understand, is it basically a way to write to arbitrary files even without permissions, basically like dirtycow?
camh-@reddit
No. The person you are replying to is wrong. This does not modify files on disk. It modifies them in the page cache in memory. See the DragonSlayerC comment that is a sibling to yours.
itscalledboredom@reddit
oh cool
DragonSlayerC@reddit
It only changes the version of su in the page cache. It'll be gone once the page is dropped, either by a reboot or
echo 3 > /proc/sys/vm/drop_caches.BlokeInTheMountains@reddit
sudo apt install --reinstall util-linux
Ytrog@reddit
Can this be used to get root on your phone if you use Termux? 🤔
chamcha__slayer@reddit
I dont think so, phones dont usually ship with su binary. Also termux itself is just a sandboxed app with no access to android's environment.
mikistikis@reddit
I guess still hard to exploit in Android because of the sandboxed environment.
lazyboy76@reddit
SeLinux? Linux also have it but not use system-wide.
Dangerous-Report8517@reddit
Some Linux distros have SELinux, and it is system wide when present, the difference is that Android has it configured to much more aggressively isolate processes, something they can afford to do because SELinux was there and enforcing right from the start rather than an after-the-fact add in like it is in Linux.
lazyboy76@reddit
I mean Linux distro set it in permissive mode (with selective enforce), that's what Android before version 7 do. From Android 7, it's enforce mode by defaults, for all manufacturers.
renshyle@reddit
Any setuid binary will do. I don't know if it'll work on Android but would be cool
Preisschild@reddit
Which is why nobody should recommend "rooting" your device unless really necessary for a specific use case. The android permissions api is much safer than suid binaries.
FeepingCreature@reddit
And if control ultimately rested with the user rather than the vendor, nobody would have to.
ballsannihilator@reddit
Android does not have any SUID binaries and apps run with no_new_privs set(SUID doesn't do anything)
requef@reddit
Why is the example program obfuscated? Is this supposed to be a codegolf challenge?
SineWaveDeconstruct@reddit
Bro exactly.. I'm not gonna run some bootleg obfuscated python script on my machine if I can't see how it works, why would they not include a clean version?
rebbsitor@reddit
Don't run this on a machine you care about. The exploit works by overwriting su.
atuncer@reddit
No, it doesn't. It overwrites the page cache version:
Because the on-disk file is never modified, there is no on-disk signature; the corruption is observed only by readers that share the page cache.
DFS_0019287@reddit
Probably to make it harder for script kiddies to weaponize it.
JockstrapCummies@reddit
If they don't want script kiddies to abuse it, surely they should have coordinated with the majority distros for a unified fix push first? You know, before public disclosure with a PoC?
DFS_0019287@reddit
They did all of that already. There's still no point in making life easier for script kiddies. Security researchers already understand how the exploit works.
Megame50@reddit
The script is just as simple to run with or without the minification. Not publishing a clean version is just a dick move.
DFS_0019287@reddit
There is a clean version of a variant at https://github.com/rootsecdev/cve_2026_31431/blob/main/exploit_cve_2026_31431.py
Megame50@reddit
That isn't really a clean version of the OP, though, which literally just replaces the first bit of /bin/su with:
Anyway I'm satisfied with the write-up, but agree with the above commenter that there's no point in obscuring the PoC.
middlenameray@reddit
here's a readable version: https://github.com/rootsecdev/cve_2026_31431
make sure to pass the
--shelloption to make it actually exec a shellsilvervest@reddit
So they can advertise it's only 732 bytes, of course.
Hithaeglir@reddit
I don't like where the world is going. All is about chasing the fame.
aliendude5300@reddit
as if it makes a fucking difference if it's 732 bytes or 3kb
silvervest@reddit
It does here, because it looks fancy and it's really a huge advertisement for their AI security platform... 🙄
LzrdGrrrl@reddit
markus_b@reddit
This does not work for me:
~$ python3copy-fail-reddit.pyTraceback (most recent call last):File "/home/markus/copy-fail-reddit.py", line 99, in <module>send_crypto_msg(su_fd, i, chunk)File "/home/markus/copy-fail-reddit.py", line 60, in send_crypto_msgop_sock.sendmsg([msg_body], ancillary_data, 0, 32768)TypeError: sendmsg(): AF_ALG address must be tuple, not intmiddlenameray@reddit
here's a readable version: https://github.com/rootsecdev/cve_2026_31431
make sure to pass the
--shelloption to make it actually exec a shellRandomPantsAppear@reddit
Unpacked by ChatGPT
import os, zlib, socket
AF_ALG = 38 SOCK_SEQPACKET = 5 SOL_ALG = 279
def hex_bytes(x): return bytes.fromhex(x)
def trigger(fd, offset, patch4): sock = socket.socket(AF_ALG, SOCK_SEQPACKET, 0) sock.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
target = os.open("/usr/bin/su", os.O_RDONLY)
payload = zlib.decompress(bytes.fromhex("..."))
offset = 0 while offset < len(payload): trigger(target, offset, payload[offset:offset + 4]) offset += 4
os.system("su")
itsbakuretsutimeuwu@reddit
Will it work on android phones?
chamcha__slayer@reddit
phones dont ship with su binary
itsbakuretsutimeuwu@reddit
Android has its own weird emulated storage, and I'm not sure how it'll play with it, if, say, some random app runs this exploit, and the phone is rooted and linux is in the affected range.
Like would it even get to su binary? Is it actually setuid or is just a prop that pretends to be setuid when you allow some app root access, thus low level mechanisms that allow copyfail to function are never touched? I don't know, I'm not an android dev.
So it'd be interesting to know.
FeepingCreature@reddit
Does it check permission by reading a file on disk?
itsbakuretsutimeuwu@reddit
I don't know, but why would reading a file restricted to root expose it to this vulnerability?
FeepingCreature@reddit
as I understand it, the exploit lets you poison the file cache of any file, no matter who owns it.
itsbakuretsutimeuwu@reddit
ah, but it's circular, I don't know if you can ness with emulated storage the same way and get the same result.
ChaiTRex@reddit
This doesn't need
su, it needs any setuid root program.2rad0@reddit
There could be other avenues, like modifying an important library file.
TheBendit@reddit
Android does not have any setuid binaries which can be run by users.
ipsirc@reddit
"Does it require /usr/bin/su?
→
No. Any setuid-root binary readable by the user works. passwd, chsh, chfn, mount, sudo, pkexec are all viable. The PoC defaults to su because it's present on every distro tested."
Audible_Whispering@reddit
Good catch, good disclosure, well done to everyone involved. However...
Words cannot express how much the LLM based writing style on that page annoys me. I'm not even particularly anti AI or anything, but the tone of breathless urgency and perfectly averaged copy writer maximum impact prose is just disgusting to read.
Just write the goddamn copy yourself, or at least prompt the LLM to sound less like an LLM.
RunasSudo@reddit
I kept trying to convince myself to power through reading on, but my goodness every time I scrolled down the page it was another punch to the face.
Bam, em dash. Bam, weak attempt at parallelism. Bam, marketing headline.
It's almost as if the LLM had been prompted to amp up the LLM-ness.
hifidood@reddit
Well this seems to be quite the "uh oh" find
rebbsitor@reddit
At least it's easily patched
nude-rating-bot@reddit
If copy_fail(): dont()
afunkysongaday@reddit
- If copy_fail(): giveroot()
+If copy_fail(): dontgiveroot()
OffbeatDrizzle@reddit
programming is easy kids!
Jaded-Asparagus-2260@reddit
IDK, seems pretty disappointing to me
JackSpyder@reddit
Plz_no()
nicman24@reddit
yeet_the_child is a function that runs on a ~1mil project
autra1@reddit
Couldn't reproduce on nixos 25.11. Permission denied. I guess we're protected by the store being mounted read-only
ava1ar@reddit
If you only read the article you will know it is not related to file system in any way. What kernel version are you running? It was patched in all supported kernels already.
autra1@reddit
You never make mistakes? I did read the article, did try the exploit. It initially failed on nixos because the suid binaries are all in a tmpfs, but I did manage to get the exploit working afterwards.
I made a mistake in my original comment yes, but it's not a reason to be so dismissive.
Dante_Avalon@reddit
Unless you have multitenant SSH (not even VM) - that exploit don't even affects you
Dangerous-Report8517@reddit
Or if you run containers, which isn't exactly an uncommon workload
aeonax@reddit
Can this get root on Android?
Dangerous-Report8517@reddit
Android doesn't have any user accessible SUID binaries to target and modify. A much more elaborate attack might be able to but only if Android exposes that API to userland, which it might not
Gnump@reddit
Debian Bookworm ist listed as vulnerable:
https://security-tracker.debian.org/tracker/CVE-2026-31431
Yet fully updated bookworm test server loads modules but does to bow to PoC:
What did I miss?
KenBalbari@reddit
https://security-tracker.debian.org/tracker/CVE-2026-31431
It's listed here as vulnerable.
goshin2568@reddit
what PoC are you using?
albertowtf@reddit
Same here
https://github.com/rootsecdev/cve_2026_31431
Gnump@reddit
https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/main/copy_fail_exp.py
pretty sure it is because 6.1 handles things a bit differently - hence the delay by the distros to backport the fix.
CamisNet@reddit
Can someone explain how it is that the exploit has been made public, yet there’s still no patch for the major server distributions?!
Dangerous-Report8517@reddit
The kernel itself was patched a little while ago, at least some versions, presumably the authors got a bit trigger happy and underestimated the propagation time for more stable/risk averse distros to get the fix into LTS kernels
Xfgjwpkqmx@reddit
Worked on my Proxmox server. Amazing. Hope they patch it soon.
Dangerous-Report8517@reddit
For what it's worth this is a kernel exploit through an API the kernel exposes to userland, so if you run only VMs on your Proxmox server it's actually still protected from this (leaving aside using it as part of an exploit chain of course)
zlice0@reddit
lol love how this gets a 7.8
overratedcupcake@reddit
It seems about right. This requires local access or chaining from a separate code execution exploit.
Dangerous-Report8517@reddit
Disagree, privilege escalation that also escapes containers since it's running through an unrestricted kernel API is massive on an increasing number of systems, this breaks a lot of security models.
albertowtf@reddit
Does it seem right? This seems the hard part of an escalation
I love seeing the same comment in another bug next to "Its not very dire but it only gives you local access. You cant do anything else with it"
The only part about right is that isnt affecting a tons of kernels. Most of my machines are ahead or behind already
yawkat@reddit
CVSS can be very misleading. It doesn't consider at all how likely a system is vulnerable, so this vuln which works on most distros but requires local access is rated lower than some request smuggling vulns that require obscure combinations of network services but are exploitable over the network.
zlice0@reddit
that's the thing. seen other LPE with higher. RCE, maybe dos, should be 7-10. but it depends on proj and from ppl ive worked with and everything i can tell, it's mostly arbitrary.
rayjaymor85@reddit
You have to weigh vulnerability with likelihood for exploitation.
You have to actually get your hands on terminal access or get a file that can be executed on to the system first.
Which arguably is the hard part in the first place...
yawkat@reddit
Yes, LPE is less serious than RCE. But LPE is still dangerous because privileges are a common defense in depth measure on Linux. And a vulnerability that is this ubiquitous and easy to exploit should not be rated lower than some of the more obscure network-level vulnerabilities.
BamBam-BamBam@reddit
You have to already have system access.
Scoutron@reddit
The guys in this thread that just updated their machine and then try to run this and go “didn’t work for me, heh, guess it’s because it’s arch” are cracking me up. These stereotypes write themselves
anh0516@reddit
Debian 13 is yet to be patched.
pangapingus@reddit
On Debian:
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
To not do anything but check, if this is =m you're likely fine-ish for now:
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
i.e. CONFIG_CRYPTO_USER_API_AEAD=m (module, as long as it's not loaded)
martyn_hare@reddit
In the land of crimson fedora hats...
>_>
gmes78@reddit
Just make sure your system is up-to-date. Fedora 42, 43 and 44 already have patched kernels.
Dangerous-Report8517@reddit
Fedora would be the blue fedora hat, they're referring to RHEL in a roundabout way
lrosa@reddit
Put
initcall_blacklist=algif_aead_initin kernel parameters.In RHEL and alike:
grubby --update-kernel=ALL --args='initcall_blacklist=algif_aead_init'pseudonym-161@reddit
What kernel is available in backports? Not that I’m worried about this on my single user desktop system.
anh0516@reddit
https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=linux-image-amd64
pseudonym-161@reddit
Thanks homie
Crihexe@reddit
I was a bit concerned about the fate of my ctf platform with RCE challenges, so I had fun making this super size-(sl)optimized Linux x86_64 no-libc ELF build of the original Python PoC for research/reproduction purposes after (hopefully) having patched it.
Current size: 801 bytes on GCC 13.3.0 / Ubuntu 24.04.
Repo: https://github.com/Crihexe/copy-fail-tiny-elf-CVE-2026-31431
Crihexe@reddit
UPDATE: 756 bytes now!
BashfulMelon@reddit
Anybody know why distros aren't treating this as a high severity vulnerability? It seems to meet Ubuntu's criteria for high but they have it at medium. Red Hat says "vulnerabilities that allow local or authenticated users to gain additional privileges" are Important, but they have it as Moderate.
What am I missing?
Euphoric_Protection@reddit
Distros weed through all the incoming CVEs and assess them for their context. Nothing in the original commit one month ago indicated any security impact beyond maybe DoS, hence they get caught blind now. Indicates they didn't get any upfront warning either.
I'm sure they'll ask reassess now and roll fixes as fast as they can.
Kudos to the discoverers.
Hithaeglir@reddit
It also feels that people want to downplay the severity until it is fixed. Once it is public information, they change the severity.
Euphoric_Protection@reddit
The maintainers often have to do so in order to not violate embargo conditions while still pushing out fixes fast enough.
shroddy@reddit
Is there a list somewhere which versions of the still supported Lts kernels are patched? How often do stable distros like Debian or Redhat update to the latest version of their Lts kernels? Only when there is a known security update or important Bugfix?
tdammers@reddit
The Debian policy is to not upgrade the kernel wholesale, but instead to apply security updates and important bugfixes individually, and then ship that patched kernel with a "patch" tag added to the version (e.g.,
linux-image-6.12.74+deb13+1, where the+1part at the end is that patch tag).The goal of this policy is to keep every package in the release functionally compatible throughout the release's lifecycle, while still fixing vulnerabilities and critical bugs.
Not sure what Redhat does, but I reckon it'll be something similar.
goshin2568@reddit
Why in the fuck did the researchers (or the kernel maintainers, or literally anybody) notify the distros???
What use is it making sure the kernel is patched prior to public disclosure if the distros haven't patched yet because they were given no notice?
eggbart_forgetfulsea@reddit
Because, as is normal, the kernel deliberately hides what it knows to be security fixes. Look at the commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
That gives us this nonsense CVE:
https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/
A bad actor might very well be looking at the Reported-by tag there and taking a closer look.
BashfulMelon@reddit
Yeah, that's the part I'm curious about.
Well, as they say, "every kernel bug is a security bug."
BashfulMelon@reddit
Also when are we getting rid of setuid binaries?
lmarcantonio@reddit
No crypto modules, not subject to the issue. It's quite simple.
aliendude5300@reddit
This whole site looks AI generated.
struct_iovec@reddit
It completely is, the bug itself was found by some morons running an AI fuzzer on the kernel source
throwawayPzaFm@reddit
Nothing moronic about it other than this comment. Just another sign of the times.
Using a new tool to do old jobs better isn't a character flaw.
inkjod@reddit
Hence, the irresponsible disclosure, I'm guessing.
ThePfaffanater@reddit
Read the website, they disclosed to the Linux kernel security team over a month before public disclosure...
Hithaeglir@reddit
Hmm, based on the severity 3 months feels better.
randuse@reddit
It's a real and quite bad bug.
inspectoroverthemine@reddit
I'm not sure what you're going for with the tone of your comment.
Are you mad someone unqualified found a bug?
Ranma_chan@reddit
100% it looks like a Claude Code composition
middlenameray@reddit
they literally stated in the disclosure that the discovery was made using AI, at the hunch of the person who kicked it off. they didn't specify which AI they used though
GolbatsEverywhere@reddit
I'm impressed they managed to directly verify the bug on "RHEL 14.3" considering RHEL 14 does not exist yet. They even included the bogus version number in the screenshot.
Hithaeglir@reddit
Happens when you use AI to generate the website?
KnowZeroX@reddit
"copy fail"
stas-prze@reddit
Maybe pastefail lmao
AlyoshaV@reddit
apparently red hat GCC reports its version as "gcc (GCC) 14.3.1 20250617 (Red Hat 14.3.1-2)", and they saw that and it overwrote the actual version number in their brain
wpyoga@reddit
Memory is expensive, they had to cut a few tokens here and there.
Im_j3r0@reddit
The entire damn thing has a strong LLM smell
agent-squirrel@reddit
Good to know the bug will still be around in 4 versions time.
d3matt@reddit
Yea, should affect 8, 9, and 10.
TheFatz@reddit
I'd like to report that Hannah Montana Linux is vulnerable. I'm scared.
shroddy@reddit
No it is not, it is based on Kubuntu 9.04 which uses a 2.6.28 Kernel, much older than the 4.14 Kernel where the bug was introduced, so you are save.
rxorw@reddit
So it is RebeccaBlackOS.
ranisalt@reddit
Why would someone vibe code a vulnerability website? Just write about it...
TRENEEDNAME_245@reddit
The whole writeup is just AI slop...
CrazyKilla15@reddit
In that case give me an unprivileged SSH shell to your machine. I can be trusted with a unprivileged SSH shell to your machine because copy.fail is AI slop and doesnt exist.
dkopgerpgdolfg@reddit
I don't think the previous commenter was denying that the bug exists, but saying that the websites content is AI slop. (And imo, yes it is).
CrazyKilla15@reddit
If the website is slop to be disregarded, why wouldnt the bug itself, which was found by AI slop, also be?
https://xint.io/blog/copy-fail-linux-distributions#how-we-found-it-9
ranisalt@reddit
You have a difficulty with words that not even the earliest models had
dkopgerpgdolfg@reddit
It's the second time that you make up things that nobody said. That's enough for an answer.
CrazyKilla15@reddit
There is no other reason to bring it up and call it slop than with the implication it should be disregarded for being slop. Don't pretend otherwise.
TRENEEDNAME_245@reddit
The entire website + text being AI slop doesn't make for the best of trusted source...
Especially when noone bothered to check (RHEL 14 ? really ?)
CrazyKilla15@reddit
So should it be disregarded or am I in the wrong for saying that was obviously what was being implied? Pick one ffs.
TRENEEDNAME_245@reddit
I'm just saying that having a CVE exploit paper be 100% AI made isn't the best way to be trusted...
The exploit exists, but the fact it's all AI made is bad
matjoeman@reddit
Finding the bug using an AI tool and writing the webpage disclosing it with AI are not the same thing.
CrazyKilla15@reddit
If you insist. What makes them different, in your eyes, such that the bug is acceptable but the page isnt?
On that note, is there even any confirmation it was written with AI? Did I miss where they disclosed they?
matjoeman@reddit
There's no confirmation but the page mentions RHEL 14.3 which doesn't exist and some of the writing was clearly done with AI, the first FAQ entry is the most obvious example.
The problem is that you can't trust the details. If they hallucinated "RHEL 14.3" then why should I trust anything on the page as useful information about how to mitigate the issue or how severely I should treat this bug?
TRENEEDNAME_245@reddit
For me it's "it's not X, it's Y", or the "list 3 things in incremental order repeatedly"
That just makes it bad to read
Erdnussknacker@reddit
That's not what they said. The issue is very real, but the site in this post is unreadable garbage.
m0x42069@reddit
Didn't they specify to the Linux creator to not make any mistakes? Rookies, so many wasted tokens
BlokeInTheMountains@reddit
Distro fail or responsible disclosure fail?
csjewell@reddit
Distro fail and (partial) responsible disclosure fail. They did make sure current versions of the kernel had patches available - they just didn't wait for distros to get the patches in their repos first. To be fair, it looks like the commits were made on April 1st, which should be enough time for the majors, but then, April 1st...
hans_s@reddit
It looks like the CVE was published on April 22nd (don't know if that already included the score). But it isn't even backported to all the upstream LTS kernels, yet.
McDonaldsWitchcraft@reddit
They didn't follow responsible disclosure guidelines because they are just a bunch of people using AI to find vulnerabilities. They might not have the necessary experience to understand what responsible disclosure is, which has been one of the biggest issues with AI cybersecurity "researchers" so far.
goshin2568@reddit
The commits were made April 1st but it seems like the distros weren't actually told what the vulnerability was. They were just guessing based on what the patch changed. All the distros have massively upgraded the severity of this on their security tracker pages since the public disclosure.
fish4terrisa@reddit
I think by default algif_aead isnt loaded? At least that'd the case in Arch.
Vogtinator@reddit
It gets loaded automatically AFAIK.
johninbigd@reddit
Isn't this a few years old now? I'd be surprised if anyone relevant was even using a vulnerable kernel now.
Scared_Bell3366@reddit
Anyone test this on Oracle Linux with the Unbreakable Enterprise Kernel? If not, I'll spin up something this evening and try it.
kreddulous@reddit
OEL8 is vulnerable when using a newer Python3 than what is provided by the distro. So I'd guess OEL9 is also. (RHEL8/9 too maybe?)
robfico@reddit
Oracle Linux 8 and 9 not vulnerable. Latest Oracle Linux 10 is vulnerable - tried the rmmod and modprobe "mitigation" but did not work - still vulnerable on OL 10.
cent 5/6/7/8 not vulnerable
ElePHPant666@reddit
let's hope 7.1 fixes the amdgpu regressions. I'm stuck on an old 6.17 kernel for now.
RetiredApostle@reddit
To test your OS:
robfico@reddit
Are you sure this proves an OS is vulnerable? I tried it on a few different distros, but POC tests all failed, even though it said vulnerable...
hyperdudemn@reddit
Yeah, that "check" just sees if algif_aead is functional. It doesn't try to leverage it as an exploit.
AF_ALG being available is a problem if the kernel has the bug; it's not the vulnerability in and of itself.
throwaway234f32423df@reddit
works on Ubuntu 24.04 with all currently-available security updates applied
doesn't work as-is on ARM (exec format error) but probably only because the example script includes x86 code, system is probably still vulnerable
doesn't work on Ubuntu WSL1, tries to do some network thing that WSL doesn't support I guess, might work on WSL2 but can't test at the moment
middlenameray@reddit
it does work on WSL2, I just tested with this non-obfuscated exploit script: https://github.com/rootsecdev/cve_2026_31431
hyperdudemn@reddit
Can you try the /etc/modprobe.d mitigation? I tried it on my WSL2 instance and it does made
sudo modprobe algif_aeaderror out, but the exploit script still works. Did some tracing and it seems that modprobe called by the kernel doesn't bother looking at the modprobe.d file...DFS_0019287@reddit
I believe another mitigation would be:
chmod go-r /usr/bin/suand the same for all other suid executables.You don't need "r" permission to run a program, just "x".
DFS_0019287@reddit
Turns out this doesn't really help, since another way to get root is to muck with /etc/passwd and that has to be world-readable.
BCMM@reddit
Well, this seems pretty bad.
Isn't this the sort of disclosure that would usually be coordinated via the linux-distros mailing list? I'm a bit confused about why it's been announced before major distros have patches ready.
Serialtorrenter@reddit
Anyone porting this to the various MIPS architectures? Think of all the embedded devices that could be vulnerable to this!
blamedrop@reddit
Very cool! Couldn't find in these two write-ups what exactly it changes in the
/usr/bin/subinary, so tried it locally.After writing this comment system healed itself and dropped that cached hacked version because I have high memory usage ;D
Each of these files is 55456 bytes long.
It changes quite a bit of the first 160 bytes:
PS. Yeah, I know I should update and restart, 79+ days of uptime right now and some totally important browser tabs that I don't want to unload/reload (because they won't load the content they're showing right now!) XD
PS2. Don't send me targeted exploits, I can handle myself, thanks!
Megame50@reddit
It's omitted because it's trivial. They just replace the very start of the binary with
execve("/bin/sh", NULL, NULL). It's suid, so that's all that's needed really.DeliciousIncident@reddit
It is rather hard to read indeed.
blamedrop@reddit
Haha, sorry - fixed. Wasn't aware old UI doesn't handle the ``` correctly - updated it to 4 spaces instead :D
blamedrop@reddit
For those playing along at home, first 160 bytes that have changes so you can view the diff yourselves:
DFS_0019287@reddit
Failed on my Debian 13 machine.
However, I'm not running the standard Debian kernel, so I guess it has been patched.
dkopgerpgdolfg@reddit
As the linked page says, kernel 7.0 (and some earlier versions) are fine.
And it also depends on how the kernel was built, and that module (if built as module) is loaded, ...
SithLordRising@reddit
Mitigating “Copy Fail” (Linux LPE) – quick actions:
Main point: Patch ASAP. Everything else just reduces risk until then.
Anyone doing anything different / better mitigation?
dkopgerpgdolfg@reddit
Not following AI bs.
Most of your points have nothing to do with this topic here.
indolering@reddit
We have tools to prevent this, we need to stop accepting this status quo.
cazzipropri@reddit
RHEL 14.3 - ok guys
DuendeInexistente@reddit
Tested this in garuda and it didn't work. Though I updated like half an hour ago and it may be already patched somehow?
Daktyl198@reddit
The bug was responsibly disclosed, and the patch went out a while ago. They wait for distros to update before disclosing the bug to the public.
CrazyKilla15@reddit
Nit: They post it to the mailing list distros follow for this, and then wait. Whatever distros do in the interim is up to the distros.
For example Ubuntu hasn't felt the need to fix the issue yet, despite having had plenty of time and the patch being on mainline since the start of aprl.
Volvo-Performer@reddit
Original commit ftom 2017 and now the fix were both added by the same github user
dkopgerpgdolfg@reddit
Author != Committer, both are visible in git.
The common part is the maintainer of this kernel subsystem, who didn't "author" the original buggy code.
marozsas@reddit
Tumbleweed 20260419-0 is not affected.
creeper6530@reddit
On my Pi running Bookworm (so even more outdated):
```
> python3 ./copy_fail_exp.py
[BOX64] Box64 arm64 v0.4.1 857991c50 with Dynarec built on Feb 19 2026 18:36:34
[BOX64] Dynarec for ARM64, with extension: ASIMD CRC32
[BOX64] Running on Cortex-A72 with 4 cores, pagesize: 4096
[BOX64] Will use hardware counter measured at 54.0 MHz emulating 3.4 GHz
[BOX64] Didn't detect 48bits of address space, considering it's 39bits
[BOX64] Counted 36 Env var
[BOX64] Library search path:
[BOX64] Binary search path: ./:bin/:/home/cooper/.local/bin/:/usr/local/sbin/:/usr/local/bin/:/usr/sbin/:/usr/bin/:/sbin/:/bin/:/usr/local/games/:/usr/games/:/home/cooper/.local/bin/
[BOX64] Looking for /usr/bin/su
[BOX64] Rename process to "su"
[BOX64] Warning, box64 is not really compatible with staticaly linked binaries. Expect crash!
$ whoami
```
creeper6530@reddit
Couldn't they make a dark mode for that we bsite???
JerryRiceOfOhio2@reddit
so a person has to have access to the pc first? ok, so, i guess it's an issue for servers with untrustworthy people on it already
NightOfTheLivingHam@reddit
that's a nasty bug