← Back to context Comment by 1p09gj20g8h 18 hours ago Where are you seeing the disabling algif_aead mitigation? 5 comments 1p09gj20g8h Reply oskarkk 18 hours ago 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 || trueEdit: and I can confirm that on my system with kernel 6.19.8 the above fixes the exploit. comfydragon 16 hours ago 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. tremon 15 hours ago 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. 2 replies →
oskarkk 18 hours ago 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 || trueEdit: and I can confirm that on my system with kernel 6.19.8 the above fixes the exploit. comfydragon 16 hours ago 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. tremon 15 hours ago 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. 2 replies →
comfydragon 16 hours ago 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. tremon 15 hours ago 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. 2 replies →
tremon 15 hours ago 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. 2 replies →
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).
`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
It should show =m if it's a loadable module, and =y if it's compiled in.
2 replies →