Cve-2026-31431

For Developers
1

https://security-tracker.debian.org/tracker/CVE-2026-31431 - see notes for details.

2

Seems like the standard images don’t have af_alg installed, aside from Starfive targets.

3

Update your distribution's kernel package to one that includes mainline commit a664bf3d603d

Until I have some better solution for this

$ git log a664bf3d603d | head -n 5
commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Mar 26 15:30:20 2026 +0900

    crypto: algif_aead - Revert to operating out-of-place

$ git log --oneline v6.12.85 | grep "crypto: algif_aead - Revert to operating out-of-place"
8b88d99341f1 crypto: algif_aead - Revert to operating out-of-place
$ git describe 8b88d99341f1
v6.12.84-3-g8b88d99341f1

git log --oneline v6.18.26 | grep "crypto: algif_aead - Revert to operating out-of-place"
fafe0fa2995a crypto: algif_aead - Revert to operating out-of-place
$ git describe fafe0fa2995a
v6.18.21-53-gfafe0fa2995a
4

Sorry, but how is that relevant?
In OpenWRT, by default, there's only the root user, and the other users don't have a shell.

5

For those who didn't find those links I mentioned:

https://github.com/theori-io/copy-fail-CVE-2026-31431/blob/main/copy_fail_exp.py - exploit.
https://xint.io/blog/copy-fail-linux-distributions - details.

6

And how does that relate to OpenWRT?
OpenWRT doesn't have a true multi-user system with sudo, etc., so there's no /usr/bin/su either.

7

That's just a demonstration. Put whatever you like instead of it.

8

Hmm, I read a little further...

For server systems used exclusively by administrative users, there is a slightly lower risk that this vulnerability could be exploited directly.

9

Slightly is the key word in that sentence. But you can continue arguing if you like.

10

Come on guys, is the hostility really necessary?
If I am understanding the CVE correctly, if AF_ALG sockets can indeed be created on an OpenWRT device, and said device has at least one service account running a vulnerable service that allows running arbitrary commands, you can poison the page cache to make the service account root, and the service will run as root the next time it starts. If the poisoned page cache is flushed to disk, the exploit will survive reboots. Not sure if uHTTPd runs as root by default, but nginx workers don't IIRC, so there may be some potential there.
Also, if you run Docker in OpenWRT, any vulnerable container can technically be exploited to manipulate the page cache of the OpenWRT device for shared files (libraries, for example), even if said device is not vulnerable.
I'm not an expert with this sort of things though, so I might be wrong. Anyone with more knowledge can chime in.

11

You can find some more context on this CVE & perhaps the poor way the disclosure was handled:

“The most severe Linux threat to surface in years catches the world flat-footed”

12

I am opening this discussion to ask about the integration timeline for the upstream kernel patches addressing the recently disclosed "Copy Fail" vulnerability (CVE-2026-31431).

The Issue: As you may know, "Copy Fail" is a logic bug in the Linux kernel's AF_ALG cryptography API that allows an unprivileged local user to escalate to root. Upstream Linux has already released patches.

13

Upstream Linux has actually released the .dot releases correcting the bug.

There is already the version bump PR for 24.10 with https://github.com/openwrt/openwrt/pull/23170

Pretty sure that there will soon be bumps also for the other branches (main, 25.12).

14

Let's hope mbedtls bug will be fixed too without waiting for 3.6.7 release :grin:

15

It looks like our main Snapshot branch is already patched as it yesterday upgraded to 6.18.25 (kernel 6.18.22 and higher should be patched)

16

Fix for K6.12 underway:

17

There is a response from @hauke regarding this vulnerability:

18

Now also 24.10 and 25.12 have been bumped to use new kernel versions that contain the fix.

So, new snapshots from all these supported branches will have the fixes in.

No idea when new .point releases will be made for the release branches, but as the bug is not that critical in a typical OpenWrt scenario, it might not be immediate. (See link to hauke's message above.)