CVE-2026-31431: Copy Fail vs. rootless containers

Original Article ↗ Hacker News Discussion ↗

Immediate Mitigations for CVE-2026-31431

  • Common workaround: prevent loading the vulnerable algif_aead module so it can’t be used while kernels are being patched.
  • For modular builds: add a modprobe rule that maps algif_aead to /bin/false.
  • For kernels where algif_aead is built-in: disable via initcall_blacklist=algif_aead_init on the kernel command line, which itself requires certain kernel config options.
  • Several commenters report that algif_aead is rarely loaded in practice and disabling it has caused no noticeable breakage so far, though edge cases are acknowledged.

Rootless Containers, Namespaces, and the Exploit

  • In rootless containers, the exploit can gain uid 0 inside the container, but this maps to an unprivileged uid on the host.
  • Some argue this “breaks” only the proof-of-concept, not the underlying primitive: page-cache writes still occur.
  • There is debate whether rootless containers “mitigate” the kernel bug or merely make this particular setuid-based escalation path ineffective.
  • Use of allowPrivilegeEscalation=False and user namespaces (--userns=auto) is suggested to reduce impact of container breakouts, but several note that the copy-fail primitive itself is namespace-agnostic.

Page Cache Corruption & Cross-Container Impact

  • Key concern: page cache is shared across containers and host when they share inodes (e.g., layered images, shared mounts).
  • A compromised container could corrupt binaries or libraries used by other containers or the host, especially if read-only mounts or shared base images are involved.
  • This can undermine multi-tenant isolation and turn read-only resources into writable attack surfaces.

Containers vs VMs as Security Boundaries

  • Some insist containers were never meant as strong security boundaries and see this CVE as a reason to favor microVMs or gVisor for hostile workloads.
  • Others argue containers still provide meaningful isolation on a continuum, just less than VMs.
  • There is disagreement on the repeated claim that “containers are not a security boundary”; some say that in practice they are treated as one, albeit a weaker one.

Seccomp, AF_ALG, and Kernel Crypto

  • Many advocate blocking AF_ALG-related syscalls in container seccomp profiles, especially given AF_ALG’s history of vulnerabilities and limited real-world use.
  • Others question disabling a kernel crypto interface globally over “one” or “a few” bugs, but counterpoints emphasize that it offers little benefit without special hardware.
  • Kernel crypto in general is defended as necessary for things like disk and network encryption, but AF_ALG in particular is criticized as overexposed and arguably unnecessary for unprivileged userspace.

Hardening Strategies Beyond This CVE

  • Suggestions include:
    • Applying strict seccomp profiles tailored per workload.
    • Using capability bounding sets and NoNewPrivileges in systemd units.
    • Running high-risk workloads in VMs or microVMs, possibly with containers inside.
  • There is acknowledgment that “default deny” syscall policies are hard because few teams know the full syscall/argument needs of their containers.

Critiques of the Article and POC Framing

  • Some readers find the article’s style “LLM-like” and object to what they see as a misleading premise that rootless containers “stop” the exploit.
  • Others defend it as an illustration of defense-in-depth: blocking an easy escalation path (setuid root on host) is still valuable, even if the primitive remains exploitable in other ways.
  • Several emphasize that the article does not prove container escape is impossible, only that this particular POC path fails under rootless setups; broader exploitability is viewed as unresolved but plausible.