Not having the module loaded doesn't mean you're not vulnerable, the kernel loads the module on-demand when it's needed. I tried the exploit on such a system, and it worked.
replyHowever, not having the module loaded does mean that in normal operation you don't need the module, so the proposed mitigation of disabling the module is safe in the sense that it won't disrupt anything.
I don't know what exactly can load this module but the servers are running for many weeks and I suppose that if something will load this module, it stays loaded until the next reboot.. no ?
replyI tried to rmmod on all servers and rmmod always returns `ERROR: Module algif_aead is not currently loaded`, that's why I think it's fine. Of course I take a look on https://security-tracker.debian.org/tracker/CVE-2026-31431 for the updates.
the kernel will autoload modules when they are needed. The fact that the module hasn't been loaded is an indication that the bug may not have been exploited, but it does not mean that you are not vulnerable to it. You need to block the module from loading or remove it entirely to mitigate the issue (which is what the first line of the recommended mitigation states).
reply> I don't know what exactly can load this module
replyWell, for one thing, opening an AF_ALG socket, as the exploit does.
rmmod just tells you it's not loaded; you'd have to delete the module to prevent it auto-loading.
reply> I have checked all the servers (bookworm, bullseye) that I manage, and none of them have the algif_aead module loaded.
replyBut only Trixie (and testing/Sid) are patched (as I type this).
On Bookworm (and Bullseye), you want to add the module to list of blocked modules. It's a one-line change.