A security bug in AEAD sockets [LWN.net]

Security analysis firm Xint has disclosed a security bug in the Linux kernel that allows for arbitrary 4-byte writes to the page cache, and which has been present since 2017. The vulnerability has been fixed in mainline kernels. A proof-of-concept script demonstrates how to use the flaw to corrupt a setuid binary, which works on multiple distributions, by requesting an AEAD-encrypted socket from user space and splicing a particular payload into it. A supplemental blog post gives more details about the discovery and remediation.

A core primitive underlying this bug is splice(): it transfers data between file descriptors and pipes without copying, passing page cache pages by reference. When a user splices a file into a pipe and then into an AF_ALG socket, the socket's input scatterlist holds direct references to the kernel's cached pages of that file. The pages are not duplicated; the scatterlist entries point at the same physical pages that back every read(), mmap(), and execve() of that file.

to post comments

Permissions problem on affected distros

Posted Apr 30, 2026 4:19 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (3 responses)

> f=g.open("/usr/bin/su",0)

On my servers:
$ find / -xdev -perm -4000 -printf "%M %p\n" 2>/dev/null
-rwsr-x--x /bin/mount
-rws--x--x /bin/ping
-rws--x--x /bin/ping6
-rwsr-x--x /bin/su
-rwsr-x--x /bin/umount
-r-sr-x--x /usr/bin/crontab
-rwsr-x--x /usr/bin/passwd
---s--x--x /usr/bin/sudo

IMHO there is zero reason for leaving a setuid binary world-readable. I started doing this 30 years ago after I found myself as a student able to disassemble them to attack them (though with availability of standard distros nowadays this is no longer a protection), but it still protects against local rootkits that search for patterns or signatures to deliver a different payload. And here it will just make the exploit fail since an unprivileged user doesn't have the permissions to open the file. With that said, it's sufficient to find *one* setuid binary to enable the exploit but on a sane system there should be zero both setuid and world readable.

Looking at my systems on Slackware, most setuid binaries (including /bin/su) are not readable either, though some are. Thus the "every distro since 2017" on the site is a bit exaggerated, it's probably "most major distros".

Permissions problem on affected distros

Posted Apr 30, 2026 4:38 UTC (Thu) by sam_c (subscriber, #139836) [Link] (1 responses)

Note that the PoC relies on suid binaries, but it is not required for this. It can poison any file, like /etc/passwd in https://github.com/rootsecdev/cve_2026_31431/blob/main/ex...

Your suggestion is probably wise to follow nonetheless, though.

Permissions problem on affected distros

Posted Apr 30, 2026 6:14 UTC (Thu) by wtarreau (subscriber, #51152) [Link]

Ah yes, /etc/passwd indeed remains a great target for this :-)

Permissions problem on affected distros

Posted Apr 30, 2026 6:16 UTC (Thu) by k3ninho (subscriber, #50375) [Link]

They note that the containerisation technologies also mean it's any write can cross the boundary, even from an unprivileged container.

K3n.

SUID needs to go

Posted Apr 30, 2026 8:53 UTC (Thu) by bluca (subscriber, #118303) [Link] (1 responses)

In other news, reason #1203129037812 why SUID binaries need to go

SUID needs to go

Posted Apr 30, 2026 8:58 UTC (Thu) by chris_se (subscriber, #99706) [Link]

It's not just SUID though, from reading through the exploit - you could also replace the cached page of /etc/passwd or /etc/shadow, for example - the SUID variant was just the easiest possible way to exploit this.

Poor coordination

Posted Apr 30, 2026 10:06 UTC (Thu) by wodny (subscriber, #73045) [Link] (12 responses)

Unfortunately the coordination process seems to be poor or non-existent[1]. Xint recommends upgrading[2] while there are no upgrades available yet. In particular Debian Stable and Oldstable are still vulnerable[3] as they use 6.1 and 6.12 kernels not yet patched upstream (at least that was the case yesterday).

[1]: https://www.openwall.com/lists/oss-security/2026/04/30/10
[2]: https://x.com/spendergrsec/status/2049616316475003243
[3]: https://security-tracker.debian.org/tracker/CVE-2026-31431

Poor coordination

Posted Apr 30, 2026 10:10 UTC (Thu) by anselm (subscriber, #2796) [Link] (2 responses)

It looks as if the current kernel in Debian oldstable (bookworm) is not actually susceptible to the PoC exploit. See https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/19.

Poor coordination

Posted Apr 30, 2026 10:16 UTC (Thu) by wodny (subscriber, #73045) [Link] (1 responses)

Yes, I have seen the issue but there is no explanation why it doesn't work. So not sure if a patch entered this version by chance or the splice/payload just needs adjusting.

Poor coordination

Posted May 4, 2026 3:51 UTC (Mon) by ebiggers (subscriber, #130760) [Link]

As far as I can tell, AF_ALG's zero-copy support was accidentally removed from the 6.1 LTS kernel last year, and thus 6.1 wasn't affected by copy.fail. This was unique to 6.1.

The zero-copy support should, of course, just be removed from AF_ALG everywhere.

Poor coordination

Posted Apr 30, 2026 11:28 UTC (Thu) by Karellen (subscriber, #67644) [Link] (6 responses)

The immediate mitigation steps described in the post should suffice for the time being though?

For immediate mitigation, block AF_ALG socket creation via seccomp or blacklist the algif_aead module:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf rmmod algif_aead 2>/dev/null

(Sorry, the command lines are in a <code> block, but it doesn't seem to be getting monospaced, indented, or using the intended whitespace, and a couple of attempts to fix it (including <tt>) aren't helping?? Maybe <code> doesn't work inside <blockquote>?)

Poor coordination

Posted Apr 30, 2026 11:47 UTC (Thu) by daroc (editor, #160859) [Link]

Hmm. I see it being rendered using a monospace font.

What we do in our articles is use a <pre> block, which should also work in comments.

Poor coordination

Posted Apr 30, 2026 14:05 UTC (Thu) by nix (subscriber, #2304) [Link]

Nothing seems to mention what the actual Kconfig symbol you should be ensuring is disabled is. It appears to be CONFIG_CRYPTO_USER_API_AEAD.

blocking algif_aead side effects?

Posted Apr 30, 2026 16:49 UTC (Thu) by dkg (subscriber, #55359) [Link] (2 responses)

I see these mitigation suggestions, but i'm also curious about what their side effects will be. Is there any common tooling that uses AF_ALG socket creation, or the algif_aead module itself?

blocking algif_aead side effects?

Posted Apr 30, 2026 22:56 UTC (Thu) by mussell (subscriber, #170320) [Link] (1 responses)

Searching through the source code of everything installed on my Gentoo system with rg 'socket([AP]F_ALG' /usr/src/debug found only 6 packages that use it: iproute2, util-linux, bluez, qtconnectivity, openssl, and ell. Out of these packages, only ell explicitly uses aead support in cipher.c. ell is depended on by bluez and iwd, and out of those two, iwd doesn't use aead support as none of the aead symbols are in the final binary. As far I know, the only thing that uses algif_aead is bluetooth-meshd.

blocking algif_aead side effects?

Posted May 4, 2026 3:48 UTC (Mon) by ebiggers (subscriber, #130760) [Link]

Yes, it's only a small set of userspace programs that made the shortsighted decision to use AF_ALG, instead of following the standard practice of using a userspace crypto library.

Help fixing these userspace programs would be greatly appreciated. It would be really impactful, as it would allow more people to disable CONFIG_CRYPTO_USER_API_* in their kernels.

Poor coordination

Posted May 1, 2026 3:19 UTC (Fri) by champtar (subscriber, #128673) [Link]

This only works if algif_aead is a module and not builtin.
RedHat has other workarounds using kargs (`initcall_blacklist=algif_aead_init`) https://access.redhat.com/security/cve/cve-2026-31431

Poor coordination

Posted Apr 30, 2026 23:24 UTC (Thu) by ATLief (subscriber, #166135) [Link]

I learned about the mitigation from a Reddit comment, half a day before it was posted on the RHEL tracker.

Poor coordination

Posted May 2, 2026 16:16 UTC (Sat) by callegar (guest, #16148) [Link]

Armbian seems to be also problematic because of an issue causing misalignment between their images and apt repos.
For instance while many images have 6.18.26 as the "current" kernel (patched), their apt repos have 6.18.10 as the most recent kernel they serve (not patched). So, if you are installing from an image today you are fine, but if you installed time ago and you rely on apt for updates you might be in trouble.

Containers

Posted Apr 30, 2026 12:13 UTC (Thu) by claudex (subscriber, #92510) [Link]

Since it works in unprivileged containers, was there any try to have the page cache separated per namespace ? I imagine it's complicated and very heavy on performance so I don't say it should be used, but I'm curious if someone tried.

The minimal fix

Posted Apr 30, 2026 16:12 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

I have no quarrel with the fix that removes the in-place operation entirely, but shouldn't there be a fix for all levels of the exploit chain? The underlying bug, as I understand it, is with the crypto_authenc_esn_decrypt() function writing extra bytes past the end of the memory it was meant to decrypt. Shouldn't there be a patch fixing that first of all?

The minimal fix

Posted May 4, 2026 17:41 UTC (Mon) by hmh (subscriber, #3838) [Link]

This contains more than just the "minimal" fix:
https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6....

It looks to me like the several issues were addressed, not just the risky in-place operation...

Why crypto in the kernel, not in user space?

Posted May 3, 2026 16:29 UTC (Sun) by marekm (subscriber, #174682) [Link] (3 responses)

Does all that crypto API really need to be exposed from the kernel to user space, adding attack surface? Is there any good reason why user space crypto libraries (which wouldn't have access to important kernel data structures like page cache) are not sufficient?

Why crypto in the kernel, not in user space?

Posted May 4, 2026 3:45 UTC (Mon) by ebiggers (subscriber, #130760) [Link]

No, it doesn't. And no, there is no good reason. I've been saying this for years.

Why crypto in the kernel, not in user space?

Posted May 4, 2026 16:58 UTC (Mon) by neggles (subscriber, #153254) [Link]

it's primarily intended as an interface for some hardware crypto acceleration engines (like AMD's CCP, on systems it works in anyway)

Why crypto in the kernel, not in user space?

Posted May 4, 2026 17:06 UTC (Mon) by mfuzzey (subscriber, #57966) [Link]

I think the reason used to be some hardware crypto accelerators that require a kernel driver to access.

The more modern way of getting hardware accelerated crypto is special CPU instructions (like the ARM cryptographic extensions) which can be used from userspace too.
But a number of older SoCs have crypto accelerators implemented as memory mapped peripheral devices so you need a kernel driver there .

However such things tend to be pretty slow, especially when used from userspace with a context switch involved. Years ago I tested the i.MX53 crypto accelerator from userspace and it was actually slower at most clock frequencies than a pure software userspace implementation. It did have the advantage however of freeing the single core CPU for other things and a small power consumption advantage too.