Copy Fail exploit CVE-2026-31431

General Privacy & Security
1

Apparently, many Linux kernels in the main distributions are affected with the “Copy Fail” exploit (CVE-2026-31431). Will there be a patch, or is PureOS not affected?

I was advised to do

```
echo “install algif_aead /bin/false” > /etc/modprobe.d/disable-algif.conf

rmmod algif_aead 2>/dev/null || true
```

in case there was no patch available, so I did this (and so far nothing weird happened).

So maybe I am ok?!

1 Like
2

Librem 5 kernel is not affected, and other devices use Debian’s kernel, so the fix will come from Debian.

1 Like
3

Note the general observation about this exploit: It doesn’t achieve anything on a single-user computer by itself. On a single-user computer it would need to be combined with some other exploit that gives a remote attacker a foothold on your computer (and that includes tricking that single-user into running some dodgy code). From there, this exploit allows a local user to gain root access. At that point, your computer is pwned.

If you have a shared computer and not all users are trusted, or you have a computer where you run untrusted code in some kind of container, you are at greater risk.

You are probably not using AEAD at all, so it should be harmless to disable it. Note that man cryptsetup still lists AEAD as “experimental” (at least as at the kernel version that I am using).

Edit: Correcting this slightly … if you are using AEAD within cryptsetup, you probably aren’t actually using the faulty kernel module … because that module is used to provide access to AEAD within userspace, whereas it is more likely that using AEAD within an encrypting device would use a direct kernel interface. So I am left wondering, purely out of curiosity, who exactly uses this module and for what application?

Here’s what Debian is showing so far: CVE-2026-31431

Or for Ubuntu: CVE-2026-31431 | Ubuntu

Edit: To make matters worse, ubuntu.com disappeared off the internet for many hours, immediately after I posted that link, reportedly due to an Iranian DDoS.

1 Like
4

Yes, but it could be used to defeat sandboxing, which in some contexts could matter even on a single-user system.

5

Covered by second paragraph.

It’s unclear which sandboxing would allow enough access in the first place. Is there a PoC for a sandbox environment?

6

Update: Ubuntu has released an update that simply disables the relevant kernel module (algif_aead), pending a properly fixed, reviewed and tested new version of that module.

The comment says:

This will likely be re-enabled in a subsequent update once an updated
kernel has been deployed.

I assume other distros would be doing something similar.

Too bad if you are in the tiny minority of users who actually use that kernel module. However I did see discussion on the internet opining that the module should not exist today (and perhaps should never have existed). So maybe the module will just disappear.

7

PureOS (Byz) latest kernel has this fixed as of April 30 last

1 Like
8

14 posts were split to a new topic: Problems with AI finding bugs in code / writing code

9

It should be noted that there has been another similar (but different) exploit published recently called “Dirty Frag”. GitHub - V4bel/dirtyfrag · GitHub . It doesn’t even have a CVE number yet.

The disclosure technically did not break the disclosure-embargo. It has mitigations (kernel module blacklisting) but no distribution-released kernel patches yet AFAIK. What happened is that someone was committing fixes related to this bug to the kernel. A kernel security expert who was not in-the-loop in regard to the bug-discussion and disclosure-embargo saw the patch and commented on the LKML that it looked like the same route as Copy-Fail. Another person, not part of the disclosure-embargo published a PoC.

3 Likes
13

Update:

can obtain root privileges on major Linux distributions by chaining the xfrm-ESP Page-Cache Write vulnerability and the RxRPC Page-Cache Write vulnerability

The xfrm-ESP Page-Cache Write vulnerability has been assigned CVE-2026-43284 and patched in mainline at […]

The RxRPC Page-Cache Write vulnerability has been reserved as CVE-2026-43500 for tracking; no patch exists in any tree yet.

This particular type of CVE proliferation is fairly normal i.e. once one security researcher points out a vulnerability, it attracts attention in a direction that often leads to “similar but different” related vulnerabilities. That’s with the latter being found by humans. It remains to be seen whether computer bug-finding exhibits the same behaviour. :wink:

1 Like
14

And one more: Fragnesia (CVE-2026-46300). No useful information in the CVE yet but e.g. Fragnesia Linux kernel local privilege escalation vulnerability mitigations | Ubuntu and PoC is already available.

All of these LPEs (Local Privilege Escalations) would pair nicely with the recent NGINX RCE (Remote Code Execution) e.g. Critical 18-Year-Old NGINX Vulnerability Enables Remote Code Execution Attacks if you happen to be running NGINX (and your config meets the other conditions). CVE-2026-42945. Which I believe Purism is. @praveen.arimbrathodi ?

1 Like
15

Thanks for the heads up, we will update our systems as soon as possible.

1 Like
16

Random observation: I believe that the HTTP Server header should be phased out. It’s just making the intruder’s job a little easier. I shouldn’t even know that you are running NGINX, much less what version. So if it is possible to configure so as to suppress that header, I would do so as well.

That said, suppressing that header is just security-through-obscurity. A motivated intruder can just try all IP addresses that respond as if a web server is present, without regard to web server software and version, and hope to hit a suitable version of NGINX by luck, which will eventually work out for the intruder.