Copy-fail-destroyer: K8s remediation for CVE-2026-31431
1–10 of 14 posts
Re: Copy-fail-destroyer: K8s remediation for CVE-2026-31431
#2Yeah run a highly privileged, node-level workload by an Internet stranger to mitigate against a kernel vulnerability. No thanks.
In any case, this unloads the module which does nothing if it's compiled into the kernel as in GKE.
Re: Copy-fail-destroyer: K8s remediation for CVE-2026-31431
#3Blacklisting a kernel module only prevents modprobe from loading it automatically. modprobe by name still works, even if the module is blacklisted, and so does insmod and the syscalls they use.
The author is way above their head and thinks that because they can write Copilot prompts they can write security critical software.
Re: Copy-fail-destroyer: K8s remediation for CVE-2026-31431
#4Blacklisting a kernel module only prevents modprobe from loading it automatically. modprobe by name still works, even if the module is blacklisted, and so does insmod and the syscalls they use. The author is way above their head and thinks that because they can write Copilot prompts they can write security critical software.
Why does it check every five minutes? Do they think the kernel is changing in a running instance faster?
Re: Copy-fail-destroyer: K8s remediation for CVE-2026-31431
#5Blacklisting a kernel module only prevents modprobe from loading it automatically. modprobe by name still works, even if the module is blacklisted, and so does insmod and the syscalls they use. The author is way above their head and thinks that because they can write Copilot prompts they can write security critical software.
Wouldn't manually loading a module require elevated privileges? Isn't the issue they are trying to solve that completely unprivileged users can exploit the module to elevate their privileges?
Re: Copy-fail-destroyer: K8s remediation for CVE-2026-31431
#6Blacklisting a kernel module only prevents modprobe from loading it automatically. modprobe by name still works, even if the module is blacklisted, and so does insmod and the syscalls they use. The author is way above their head and thinks that because they can write Copilot prompts they can write security critical software.
Wouldn't manually loading a module require elevated privileges? Isn't the issue they are trying to solve that completely unprivileged users can exploit the module to elevate their privileges?
Let's consider a sysadmin who says "I blacklisted this module, so we shall never see it on this system."
And then, some random service or cronjob goes down a list and "modprobes" things. Such as a vulnerability scanner.
So the kernel module got loaded by name, until the next reboot.
Yeah, it's another coincidence and another narrowing of the conditions by which this can be exploited. But it's correct to say that blacklisting modules is not the panacea or a 100% airtight solution.
Re: Copy-fail-destroyer: K8s remediation for CVE-2026-31431
#7Blacklisting a kernel module only prevents modprobe from loading it automatically. modprobe by name still works, even if the module is blacklisted, and so does insmod and the syscalls they use. The author is way above their head and thinks that because they can write Copilot prompts they can write security critical software.
Wouldn't manually loading a module require elevated privileges? Isn't the issue they are trying to solve that completely unprivileged users can exploit the module to elevate their privileges?
I just tried it on Ubuntu 24.04. Blacklisting algif_aead does not prevent the module from getting loaded by `nobody` using the unprivileged AF_ALG API.
So this project literally does nothing except spew some vibe coded slop across your cluster. Please just upgrade your kernel packages, it's way safer.
Re: Copy-fail-destroyer: K8s remediation for CVE-2026-31431
#8Just use chef or whatever configuration management system of choice.
Re: Copy-fail-destroyer: K8s remediation for CVE-2026-31431
#9The k8s remediation is setting allowPrivilegeEscalation to false, which you should have already been doing if you follow the in-tree Pod Security Standards at the Restricted profile.
Re: Copy-fail-destroyer: K8s remediation for CVE-2026-31431
#10Blacklisting a kernel module only prevents modprobe from loading it automatically. modprobe by name still works, even if the module is blacklisted, and so does insmod and the syscalls they use. The author is way above their head and thinks that because they can write Copilot prompts they can write security critical software.
Why does it check every five minutes? Do they think the kernel is changing in a running instance faster?
AI made this decision. It seems that the (human)? operator didn't review that.