that just prevents the faulty module from loading. So you have time to fix it properly (kernel upgrade)
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
This isn't a new CVE. It's just documenting what happened when this person ran the exploit inside a certain type of container.
tl;dr (not from article)
that just prevents the faulty module from loading. So you have time to fix it properly (kernel upgrade)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
Though this won't work for some kernels:
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.
Dumb question: is preventing the module from loading safe to blindly run on, e.g., Unraid, Proxmox, WSL2? Is it possible to break anything?
It already has a table of contents. The heading titled "why rootless containers stopped the escalation" is your tl;dr.
[dead]