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

Original Article ↗ Hacker News Discussion ↗

A Linux kernel vulnerability dubbed “Copy Fail” (CVE-2026-31431) allows unprivileged users to corrupt read‑only page cache contents via the AF_ALG crypto interface, enabling privilege escalation and potentially poisoning shared binaries or libraries. Commenters examine how rootless containers and user namespaces can prevent a simple “become host root” outcome while still leaving the underlying page‑cache corruption primitive intact, which can be abused across containers that share image layers or host mounts. Mitigations discussed include disabling the vulnerable algif_aead module, tightening seccomp profiles to block AF_ALG, and in higher‑risk environments favoring microVMs or stronger sandboxing over containers as an isolation boundary.

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.