Please post a tl;dr at the top or even in the subject. Many of us are scrambling to patch/reboot our **.
echo -e 'install algif_aead /bin/false\n' > /etc/modprobe.d/disable-algif.conf
Technically there should be zero impact (the very very few tools that use it will fall back to userspace), I haven't even found that module loaded in infrastructure
Then check if it is loaded, and if it is, unload/reboot
It could fail though. But I have not yet heard of anyone noticing big problems due to disabling the problematic modules. And I have not noticed any such issues on our systems at ${DAYJOB}.
IMHO, since these parts of the Linux kernel are so crappy I personally would say disabling them is a good default choice. YMMV. But if you encounter problems, then you can always re-enable the modules. (Preferably after upgrading your kernel, obviously.)
If algif_aead was a builtin module, it needs to be disabled by adding initcall_blacklist=algif_aead_init to the boot cmdline.
However initcall_blacklist requires the kernel to be built with CONFIG_KALLSYMS.
My concern is to try to understand the mechanisms of the exploit.
Copy Fail is not simply ”hey, kernel, give me root”. I would say it’s more general than that. It’s rather: ”Hey, kernel, when you present file /foo to a process, make the contents of that file appear according to my wishes”. Which can be used (in various ways) to advance the attacker’s position.
That’s why I think it’s interesting to ponder if that power allows the attacker to simply sneak past security policies such as allowPrivilegeEscalation=false.