On Mon, Jun 22, 2026 at 04:48:03PM -0700, Eric Biggers wrote: > AF_ALG is a frequent source of vulnerabilities and a maintenance > nightmare. It exposes far more functionality to userspace than ever > should have been exposed, especially to unprivileged processes. Recent > exploits have targeted kernel internal implementation details like > "authencesn" that have zero use case for userspace access.
I absolutely want to see this attack surface reduction. > Add a sysctl /proc/sys/crypto/af_alg_restrict with meaning: > [...] > Note that the list may be tweaked in the future. However, the common > use cases such as iwd and bluez are taken into account already. I've > tested that iwd still works with the default value of 1. I wince at this bit, though. This is a "security policy in the kernel" which we try to avoid, and it's could be done already in userspace with modprobe blacklist. But, as you say, AF_ALG is deprecated. I understand that to mean that the alg list is only ever going to *shrink* in the future. Using a sysctl means monolithic kernels are protected, but wouldn't those systems just compile AF_ALG out? So, I guess, I would want a more clear rationale for why we do it this way instead of via modprobe blacklist. I see a few reasons, but they don't really convince me that we should ignore the "no security policy in the kernel" rule to do it this way. -Kees -- Kees Cook
