Copy-fail-destroyer: K8s remediation for CVE-2026-31431(github.com)
18 pointsby evenh2 days ago4 comments
  • antiloper2 days ago
    Blacklisting 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.

    • Bendera day ago
      modprobe by name still works, even if the module is blacklisted, and so does insmod and the syscalls they use.

      Agreed. There is a way but I would never recommend it to anyone. Showing just for completeness sake in the event anyone else suggests it but do not do this and certainly never put it in a config file or "bad things will happen ©2009-2026".

          # rmmod the module of concern first, then if that exits with the correct exit code:
    sysctl -w kernel.modules_disabled = 1
    sysctl -w kernel.kexec_load_disabled = 1
      Once activated these settings will remain immutable until reboot. These settings can break OS updates among a myriad of other things. Calculating risk requires a dungeon leader, 4d20 dice and 12 magic 8-balls to form a quorum. Probably safer to just limit access based on role and then update the OS as soon as it is feasible to do so. Leave the role based access controls in place. If anyone complains add them to the on-call rotation.
    • bombcar2 days ago
      Why does it check every five minutes? Do they think the kernel is changing in a running instance faster?
      • subscribed2 days ago
        AI made this decision. It seems that the (human)? operator didn't review that.
    • petjuha day ago
      OK, how about this then:

          sudo rm "$(modinfo -n algif_aead)"
      Nice and simple. Or if we want to be more thorough:

          modinfo -n algif_aead && sudo mv "$(modinfo -n algif_aead)" "$(modinfo -n algif_aead)_"
    • glacier91472 days ago
      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?
      • antiloper2 days ago
        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.

      • ButlerianJihad2 days ago
        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.

  • cassianoleal2 days ago
    Yeah 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.

    • red-iron-pine2 days ago
      here i've got this USB that will fix any vulns on your system.

      just plug it in and click the .exe file

      • rolpha day ago
        thats kewl, i have a keyboard that will fix any haxx, just plug it into the USB and wait til its finished being 12ec09n1z3d by the system.

        no sudo permissions required, it takes care of that nonsense.

  • parliament322 days ago
    The 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.
  • __turbobrew__2 days ago
    Just use chef or whatever configuration management system of choice.