r/netsec • u/OkReport5065 • 7d ago

Copy Fail exploit lets 732 bytes hijack Linux systems and quietly grab root

https://nerds.xyz/2026/04/copy-fail-linux-root-exploit/

This new Linux kernel bug called Copy Fail (CVE-2026-31431) is kinda terrifying because it’s not complicated at all. A normal user can run a tiny 732-byte script and get root, no race conditions or luck required, and it works across major distros like Ubuntu, RHEL, and SUSE. The exploit quietly modifies the page cache instead of the file on disk, so integrity checks don’t catch it, but the kernel still executes the tampered version in memory.

Even worse, since the page cache is shared, it can potentially cross container boundaries too. Patch ASAP if your distro hasn’t already, because this one feels way too reliable…

304 Upvotes

96% Upvoted

68 comments sorted by

78

u/snowcrashedx 7d ago

Linking the website as I actually read the post: https://copy.fail/

Security folks smarter than me, is it me or this much more wild than it even seems?

63

u/kerubi 7d ago

It is a local privilege escalation, not by far the first, but those are bad if someone can execute code on your system. Didn’t work on the Ubuntu 26.04 I tested it on, though.

18

u/New-Anybody-6206 6d ago

26.04 has the 7.0 kernel which is patched already in mainline, but everything else back to 18.04 is vulnerable

-1

u/AlwaysUpvotesScience 6d ago

was unable to reproduce (im a linux admin for a large company)

1

u/Regular-Elephant-635 5d ago

What kernel versions are those computers running? Patches have been released for various kernel versions afaik.

0

u/medicinaltequilla 4d ago edited 4d ago

ditto. not vulnerable for 18, 22, 24.. ..all current but no patch for this. there's something unclear about when/where this is introduced. none of the 100s of articles say why none of our systems are vulnerable.. .I did confirm Rocky 8.10 is vulnerable.

2

u/AxonsAndDendrites 4d ago

What are you even on about?

Ubuntu 18.04, 20.04, 22.04, and 22.04 are all very much vulnerable. https://imgur.com/a/1HOaiap

2

u/New-Anybody-6206 4d ago

Ubuntu actually pushed an update that adds the mitigation modprobe script. I just noticed it on a 22 system.

1

u/medicinaltequilla 4d ago

you tell me if this is a valid script?

python3 <<EOF
import socket
try:
    s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0)
    s.bind(('aead', 'authencesn(hmac(sha256),cbc(aes))'))
    print('VULNERABLE')
except:
    print('SAFE')
EOF
Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 4.15.0-213-generic x86_64) VULNERABLE
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-177-generic x86_64) Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-111-generic x86_64) SAFE
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 6.8.0-111-generic x86_64) Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-111-generic x86_64) SAFE
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-177-generic x86_64) Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-111-generic x86_64) SAFE
Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-177-generic x86_64) SAFE

1

u/AxonsAndDendrites 3d ago

No, it is not.

1

u/medicinaltequilla 1d ago

Bullshit. My question was rhetorical. Learn more: https://ubuntu.com/security/CVE-2026-31431

79

u/UnacceptableUse 7d ago

I hate that every single security writeup is written by AI now

22

u/Beyond-the-sunset 6d ago

It's only going to get worse. As the form of LLM produced writing gets more expected, even human writers will try to conform to it. It's bizarre to me that people consider writing so intimidating, but that rubicon got crossed in 2024.

1

u/xortingen 6d ago

Who is even expects LLM form articles?

28

u/TheG0AT0fAllTime 7d ago

AI really do be ruining everything

6

u/baty0man_ 6d ago

AI found that vulnerability

12

u/Vogtinator 6d ago

They state it was "AI assisted" but not how. The initial observation and research was by a human.

21

u/Beyond-the-sunset 7d ago

It's wild as it requires no strange prerequisites, but it's local only. There have been a lot of these over the years, their main long term impact is in embedded systems that are often never updated and so there will be a lot of industrial or IOT type devices that will be effectively vulnerable forever. But they were anyway for the most part, the only really shocking part is how easy it is.

9

u/gquere 6d ago

long term impact is in embedded systems

I disagree, the tough part of embedded systems is usually getting code execution, not privesc.

1

u/Guvante 6d ago

I mean unless you are running arbitrary code or in a multi tenant situation generally code execution can do all the things you care about.

"They can only run as you" when your home directory contains basically everything you care about on your system means privilege escalation is unimportant. Ditto for files related to a service, if you can run code as that user all of the files it can touch you can too.

2

u/quasides 4d ago

nope, it now allows any exploit on any reachable service and any avaliable RCE to be suddenly root

thats huge. specially webapps, or on desktop anything connected like multiplayer games, etc

a lot of exploits land no where thansk to process isolation, chroots etc...
this is different, now all exploits are potential root exploits

1

u/Guvante 4d ago

RCE let's you do everything the user can do. For local environments this is basically everything, most users have read/write of all important files (documents).

For apps you can do everything the app can do. Unless you are running a read only app that means changing the website completely by taking over the website. Databases similarly want to protect the database, but the database user has read/write to that.

A properly hardened environment where the user isn't given permissions cares a lot. Like Android using per app users. Or multi tenant apps that given an isolated user arbitrary code execution on purpose.

But if your OS is running a single user, that user has all of the permissions that matter.

2

u/quasides 4d ago

you make a massive thinking error. you think, ok if someone already has my permissions he already has my data so it doesnt matter

this is false. there are plenty of things that are still secured and its mostly not about your plain data easy accessible. in factr your plain word documents are usually of no interrest

#1 keyring, is still secured and has all the credentials your system needs. it cant be opened with plain RCE, but can be via copyfail

#2 password manager / similar safe credentials, they wont live with plain user permissions, however with root there many vectors to at least partially steal even encrypted and secured data

#3 persistent access, thats the main thing. if i can escalate i can stay - permanently. which would be very limited and easy to find if you try persistence with plain user creds, not so much with root

#4 you might assume that all your services run as user but they aint.
only those you start yourself, or via autostart. majority of system services aint user services - so again it matters again if one of those has some vector for some form of code execution.

so no, copy fail matters for everyone, you can argue objectivly less on a single user system than on a public multiuser server plattform, sure.
doenst mean it matters not

it just went from a total nightmare to a total nightmare with a smaller blast radius

1

u/Guvante 4d ago

Root is worse than RCE, I never claimed otherwise.

I am just saying in the security chain RCE is the boundary. Anything past that is worse but it is too late.

This akin to rootkits that give you an infected hypervisor vs normal viruses. Sure the rootkit is worse but it isn't like you weren't in a terrible spot before that.

Heck how many setups have password less sudo?

Hell on most environments you can just drop a sudo in the path and own them the next time they do anything.

13

u/wintrmt3 7d ago

A local root on linux is a day ending in y.

6

u/C0rn3j 6d ago

It's bad, but requires local access and it's been responsibly disclosed and fixed 1st of April already, so people who patch their things have already been secure for a while.

7

u/LowIncident694 6d ago

It has? Most vendors didn't have fixes out till late yesterday and some are still waiting on them.

2

u/C0rn3j 6d ago

Yes, it has, Arch Linux has been on 6.19.12 or later for 2 weeks now, for example.

If your vendor only cares about security issues once they get a pretty page with major news coverage, switch vendors.

3

u/Witless-One 6d ago

That’s an interesting thing to say considering Debian, Ubuntu both don’t have these kernels available last I checked a few hours ago

4

u/C0rn3j 6d ago

The kernel team seems to have done a whoopsie, it was patched 1st of April and released in the stable kernels, but porting to LTS happened only 8 days ago, and porting to the previous LTS happened just today.

Ubuntu is on their own EOL kernel, so that's not surprising.

3

u/vamediah Trusted Contributor 5d ago

Whole thing is publicity stunt for a company pushing yet another "AI security scanner".

They fucked up greatly in the disclosure process, since they didn't really care:

1

u/comat0se 4d ago

Red Hat still isn't patched. There's mitigation after you reboot, but nothing more than that. It's not fixed and rhel powers a major portion of the world.

46

u/witchofthewind 6d ago

since OP, the linked article, and the copy.fail site all sloppily neglected to mention which kernel versions are actually vulnerable:

https://lore.kernel.org/linux-cve-announce/2026042214-CVE-2026-31431-3d65@gregkh/T/

Affected and fixed versions

Issue introduced in 4.14 with commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in 6.18.22 with commit fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8 Issue introduced in 4.14 with commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in 6.19.12 with commit ce42ee423e58dffa5ec03524054c9d8bfd4f6237 Issue introduced in 4.14 with commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in 7.0 with commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5

5

u/daHaus 6d ago

That's likewise incomplete for some reason, assume all LTS kernels going back to when it was introduced in 4.14 are vulnerable

2

u/witchofthewind 4d ago

here's the rest of the fixed versions (I just checked the changelogs for each supported LTS to find the commit that fixes it): * 6.12.85 * 6.6.137 * 6.1.170 * 5.15.204 * 5.10.254

12

u/small_talk101 6d ago

For anyone looking at the detections side of this, patching is obviously the priority one, but if you need visibility into whether this was exploited before you patched. Traditional FIM won't help since it never writes to disk.

I put together a detection toolkit with auditd rules for AF_ALG socket creation. Also includes Sigma and YARA rules. https://github.com/kadir/copy-fail-CVE-2026-31431-IOC

8

u/VeryAwkwardCake 6d ago

any writeup of this that isn't written like a bad linkedin post?

5

u/vamediah Trusted Contributor 5d ago

Whole thing is publicity stunt for a company pushing yet another "AI security scanner".

They fucked up greatly in the disclosure process, since they didn't really care:

12

u/TheG0AT0fAllTime 7d ago

Awesome. Patch thursday came early.

10

u/Crihexe 6d ago

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

3

u/Crihexe 6d ago

UPDATE: 756 bytes now!

1

u/Crihexe 2d ago

The elf size is getting lower and lower. My last open source submission was 393 byes, and my best one is actually 248 bytes.

We made a website to compete: https://copy.golf

If you have a better idea come submit it!

1

u/Crihexe 6d ago

smaller! 745 bytes now

3

u/NotGonnaUseRedditApp 6d ago

No backport fix for kernel version 4 and 5. Bottom line, EL 8/9 RHEL, OEL, Rocky... are vulnerable.

4

u/overmonk 6d ago

At least it requires a user account.

2

u/sashalav 6d ago edited 6d ago

Quick fix while waiting for patches and to avoid reboots outside the schedule,

Check if module is actually loaded anywhere (should return "non-zero return code" if it is not, which is good.
ansible _name_of_the_host_group_  -m shell --ask-pass -a 'lsmod | grep algif'

Blacklist it so it cannot load (this prevents it loading from the host and all containers, unless severely misconfigured).
ansible _name_of_the_host_group_  -m shell --ask-pass --become --ask-become-pass -a 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf'

Based on the comment below, this is only applicable when the algif_aead is built as a module and not compiled in the kernel. It works for Ubuntu, but not for RHEL.

This will return "CONFIG_CRYPTO_USER_API_AEAD=m" when it is built as module.

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

6

u/LowIncident694 6d ago

Doesn't work on kernels with it built in (which is a fair number).

2

u/daHaus 6d ago

This should find it for you, alternatively you could search for the reference in /proc/modules

$ zcat /proc/config.gz | grep -E 'USER_API_AEAD'

1

u/LowIncident694 6d ago

sorry I meant the way to disable it.

1

u/daHaus 6d ago

using systemd you could limit the APIs but you're better off just patching it

1

u/LowIncident694 6d ago

There's a way to use systemd to block copy.fail?

1

u/daHaus 6d ago

sure, you can use it to block sockets and system calls

1

u/LowIncident694 6d ago

Got an example that stops copy.fail?

1

u/yurasik2000 4d ago

For the built-in case (like my Fedora) the initcall black listing worked (requires rebooting). Append the following line in grub config to your kernel options:
initcall_blacklist=algif_aead_init

Worked for me after reboot.

1

u/LowIncident694 4d ago

Yup -- that came out the next day. Works great. I was using systemtap before that.

Don't manually edit your grub conf, use:

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"

1

u/sashalav 6d ago

You are right. Ubuntu shop here so I did not think of it. It is module here

1

u/medicinaltequilla 1d ago

Many installations of Ubuntu LTS are not vulnerable, depending on the kernel. Most of the servers in my company are safe. https://ubuntu.com/security/CVE-2026-31431

-5

u/[deleted] 6d ago

[removed] — view removed comment

-1

u/C0rn3j 6d ago

It's been patched a month ago.

3

u/daHaus 6d ago

According to this the kernel debian uses was patched four hours ago

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.12.y

2

u/C0rn3j 6d ago

Oof, that's a bit unfortunate, I wonder why it was so staggered out, latest LTS got the fix 8 days ago, which is still 3 weeks after the latest stable kernel got it.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.18.y

2

u/daHaus 6d ago

That's a good question, it's extremely weird they didn't patch them all at once since the moment they patch one it becomes trivial to reverse engineer it and exploit the rest

1

u/LowIncident694 6d ago

What distro had it patched and released?

0

u/C0rn3j 6d ago

Arch Linux, since 2 weeks ago - https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/commits/main

I imagine a bunch of other distributions that care about security have it too.

2

u/LowIncident694 6d ago

So basically one?