On a git repo that has as remotes

    https://github.com/torvalds/linux.git
    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git as remotes:

running a search for commit a664bf3d603d's commit message:

    git log --all --grep 'crypto: algif_aead - Revert to operating out-of-place' '--format=%H' | xargs -I '{}' git tag --contains '{}' | sort -u

outputs these tags as having the fix:

    v6.18.22
    v6.18.23
    v6.18.24
    v6.18.25
    v6.19.12
    v6.19.13
    v6.19.14
    v7.0
    v7.0.1
    v7.0.2
    v7.0-rc7
    v7.1-rc1

Here's the diff if you wanna play in your source (Gentoo, looking at you):

https://github.com/torvalds/linux/commit/a664bf3d603d

6.18.25-gentoo-x86_64 has the patch for Gentoo.

Thanks a lot!!!

I was running in Gentoo "6.18.18" (amd64) and the exploit worked (and all other shells which I PREVIOUSLY opened could then just execute "su -" without password to become "root") -> doing temporarily a "modprobe -r algif_aead" on-the-fly did not fix it as I was still able to swap to "root" from the unprivileged user by executing just "su -".

"6.18.25" fixed it (module "algif_aead" still running).

- Maybe older Kernel versions that don't contain the fix should be blacklisted?

- FYI in Gentoo I had to recompile "sys-fs/zfs-kmod" after the minor kernel upgrade (I initially skipped it, but after rebooting with the new kernel I could not mount my raidz1) -> the same might be needed for other external modules.

Yeah in theory genkernel should handle zfs but since I’m zfs_on_root because I like living dangerously I have a one liner that genkernels and then re-emerges zfs and then rebuilds the initramfs.

distros might also apply patches to their own packages, so this isn't a perfect signal (i.e. if you have one of those versions, you almost certainly have the fix, but if you don't, it might still be fixed but you'll need to check the distro's package information to know for sure).

Just curious.. do they list all those kernel version because there is regression in versions after 6.18.22 ?

ie does v 6.19.0 have the flaw in it?

No, it was fixed initially in 7.0, and the patch then applied to the 6.18 and 6.19 branches, fixing the existing bug in versions 6.18.22 and 6.19.12. The bug exists in 6.19.0 to 6.19.11, but not as a regression - those were all released before the bug was fixed.

Major os vendors will publish pages with the fixed versions:

https://security-tracker.debian.org/tracker/CVE-2026-31431

https://ubuntu.com/security/CVE-2026-31431

Also, disabling algif_aead is suggested as mitigation

Where are you seeing the disabling algif_aead mitigation?

In TFA: https://copy.fail/#mitigation

> Before you can patch: disable the algif_aead module.

> echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

> rmmod algif_aead 2>/dev/null || true

Edit: and I can confirm that on my system with kernel 6.19.8 the above fixes the exploit.

Weirdly, the mitigation does not seem to work under WSL2 (at least in Ubuntu 24.04).

    Linux wsl2 6.6.87.2-microsoft-standard-WSL2 ...

`modprobe algif_aead` errors out, but if I run the POC, it succeeds.

Outside of WSL2, the mitigation does appear to work though.

It's possible that the WSL kernel has that code compiled-in rather than as a loadable module. If they ship the kernel config somewhere, you could verify with

  zgrep CRYPTO_USER_API_AEAD /proc/config.gz /boot/config-*

It should show =m if it's a loadable module, and =y if it's compiled in.

It's a loadable module:

    CONFIG_CRYPTO_USER_API_AEAD=m

Using bpftrace to watch calls to module_request, openat, etc., it looks like when the kernel calls modprobe, it doesn't even look at the disable-algif.conf file:

    [module_request] pid=3648 comm=python name=algif-aead
    [umh_setup] pid=3648 comm=python path=/sbin/modprobe argv0=/sbin/modprobe argv1=-q argv2=-- argv3=algif-aead argv4=
    [openat] pid=3688 file=/etc/ld.so.cache
    [openat] pid=3688 file=/lib/liblzma.so.5
    [openat] pid=3688 file=/lib/libz.so.1
    [openat] pid=3688 file=/lib/libgcc_s.so.1
    [openat] pid=3688 file=/lib/libc.so.6
    [openat] pid=3688 file=/etc/modprobe.d
    [openat] pid=3688 file=/lib/modprobe.d
    [openat] pid=3688 file=/lib/modprobe.d/dist-blacklist.conf
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.softdep
    [openat] pid=3688 file=/lib/modprobe.d/systemd.conf
    [openat] pid=3688 file=/etc/modprobe.d/usb.conf
    [openat] pid=3688 file=/proc/cmdline
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.dep.bin
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.alias.bin..
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.symbols.b..
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.builtin.a..
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/modules.builtin.b..
    [openat] pid=3688 file=/sys/module/algif_aead/initstate
    [openat] pid=3688 file=/sys/module/af_alg/initstate
    [openat] pid=3688 file=/sys/module/algif_aead/initstate
    [openat] pid=3688 file=/lib/modules/6.6.87.2-microsoft-standard-WSL2/kernel/crypto/alg..
    [finit_module] pid=3688 comm=modprobe fd=0 flags=0
    [module_load] pid=3688 comm=modprobe name=algif_aead

Restart WSL2, run the bpftrace, and try `sudo modprobe algif-aead`, and that shows it looking at (or I guess opening) other files in /etc/modprobe.d, including the new one.

The mystery is why.

In wsl, each distro you have runs in a container (with lot of permissions), you'd need to apply the modprobe change inside wsl "hypervisor" rootfs

The only way to solve this issue in WSL is to rebuild your kernel:

~ uname -r

6.18.20.3-microsoft-standard-WSL2+