Poor coordination [LWN.net]

Poor coordination

Posted Apr 30, 2026 11:28 UTC (Thu) by Karellen (subscriber, #67644)
In reply to: Poor coordination by wodny
Parent article: A security bug in AEAD sockets

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 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