Poor coordination [LWN.net]

Poor coordination

Posted Apr 30, 2026 10:06 UTC (Thu) by wodny (subscriber, #73045)
Parent article: A security bug in AEAD sockets

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

to post comments

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.