Copy-Fail Shows Why Container Security Still Depends on the Host Kernel

TL;DR

CVE-2026-31431 — Researchers dubbed it Copy-Fail — lives in a place most container security checklists don't look: the Linux kernel's AF_ALG crypto subsystem, not the container image, the registry, or a base-image CVE feed.[4] Docker's own framing is unambiguous: "The correct fix is a kernel update." The mitigations shipped in Docker Engine v29.4.3 exist for the gap between disclosure and the moment your distribution actually ships that patch.[4] That gap is the real subject of this post, because the gap between an Engine upgrade and a kernel patch is easy to manage as two unrelated tasks. The practical answer is a patch-cadence discipline, not a single fix: patch the kernel first, upgrade Engine as a bridge while the kernel patch is pending, and review inherited seccomp, AppArmor, and SELinux profiles rather than assuming they still fit. The same layered logic extends directly to AI code execution — a hardened sandbox for generated code still sits on the same shared host kernel, so both layers need their own patch discipline. For AI workloads, the lesson is operational: the host kernel remains part of the security boundary, and a mitigation is not proof of a fix.

What the vulnerability actually changes

Docker describes the flaw as sitting in the algif_aead module and letting an unprivileged user with access to an AF_ALG socket perform controlled writes to the page cache.[4] The page cache is shared at the host level, which is the operational detail that matters more than the CVE number: a process that starts inside a container can still reach a kernel surface whose consequences are not contained by the container boundary at all. Namespaces and cgroups isolate a great deal. They do not isolate the kernel itself, because there is only one kernel, and every container on the host is a tenant of it whether the security model admits that or not.

The correct fix versus the available mitigation, and why the difference matters

Docker is explicit that a kernel update is the real fix, and says so in language that leaves no room to read the Engine release as a substitute.[4] What Engine v29.4.3 actually does is narrower: it blocks AF_ALG socket creation through the default security profile and adds AppArmor and SELinux protections in the same release.[4] Those layers reduce exposure for a workload that has not yet received the kernel patch. They are not the patch. Treating a mitigation as a fix is a specific, recurring mistake — teams patch the software they update automatically and quietly skip the layer that update pipeline was never built to touch.

Why the first mitigation attempt broke compatibility

The first seccomp-based approach broke 32-bit binaries, and a later release had to adjust the policy while keeping the defense-in-depth controls intact.[4] It's a small detail with a larger lesson: a security change to a default profile is still a change to production behavior, and it can break a workload that has nothing to do with the vulnerability being mitigated. The safe rollout sequence is not "enable the rule everywhere and watch the dashboards." It's inventory first, test against a realistic workload set, observe denials before they become outages, and keep an actual rollback path rather than a hope that one exists.

A Netics host actually facing this question

Imagine a Proxmox host running several containers and VMs on one shared kernel: it is the kind of host this advisory requires operators to examine. The question a vulnerability like this one actually asks is not "did I update my container images" but "what kernel is running underneath them, and when did it last change" — and that second question needs an answer tracked on its own, separately from whatever is running inside the containers and VMs on top. A scan limited to image digests does not evaluate the host-kernel state where this vulnerability lives, so image evidence cannot replace host patch verification.

The stakes are higher on a host that runs more than one tenant's workload. Docker is specific about the scope here: the page-cache write reaches other workloads that map the same affected file, which includes containers built from a shared image layer, not automatically every container on the host regardless of what it mounts.[4] When a shared host runs several clients from common base images, that overlap is a possibility to verify, which is why the kernel patch cadence has to be a first-class operational item with its own owner, not an afterthought bundled into whichever maintenance window has spare capacity. A host running client A's workload and client B's workload on the same unpatched kernel, sharing the same base image layer, does not have two separate security postures. It has one, and it is only as strong as the weaker client's patience for downtime.

A practical remediation sequence

Start by identifying which hosts and containers are running an affected Engine or kernel version — you cannot mitigate what you have not inventoried. Apply the distribution's kernel patch as soon as it is available and reboot according to your normal change procedure, because a kernel patch that is downloaded but not loaded protects nobody. Where the kernel remains exposed in the meantime, upgrade Docker Engine to v29.4.3 or later. Review privileged containers, added capabilities, host mounts, and any custom seccomp, AppArmor, or SELinux settings that predate this advisory, since those are exactly the configurations most likely to interact badly with a new default profile. And if an upgrade has to be delayed for a legitimate reason, write the exception down with an owner and a date, rather than letting it become permanent by default.

Docker also documents temporary options such as blacklisting the affected module or applying a custom seccomp profile, and is careful to repeat the same caveat each time: these reduce exposure, they do not fix the kernel.[4]

What not to conclude from any of this

Do not conclude that containers are inherently unsafe, and do not conclude that Docker "fixed" Copy-Fail with the Engine release, because neither claim survives contact with what Docker actually wrote.[4] The precise, narrower conclusion is that a container runtime can reduce exposure to a vulnerable host surface while the host still needs its own, independent patch lifecycle — two separate obligations that happen to sit on the same machine. A non-root container is not an automatic exemption either. The question that actually determines exposure is whether the workload can reach the affected socket path at all, and which kernel is sitting underneath it right now.

It is also worth resisting the opposite temptation: treating the Engine mitigation as unnecessary because "the real fix is the kernel anyway." The two are not competing options, they are sequential ones. Distribution kernel patches do not arrive everywhere on the same day, and the interval between disclosure and a patched kernel actually landing on a given host is exactly the window the Engine mitigation is built to shrink. Skipping the mitigation because a kernel patch is theoretically coming later leaves that entire window open for no operational benefit.

What this means for AI workloads specifically

The same lesson applies directly to agents that generate and execute code. Google's zero-trust ADK guidance recommends user-space isolation, no network egress, resource limits, and deterministic gates around exactly this kind of generated-code execution.[1] Containerizing the code runner is a necessary control. It is not sufficient if the host, the capability set, the mounts, or the kernel patch policy underneath it are unmanaged, because a sandboxed process inside a vulnerable kernel is still standing on the surface the vulnerability affects. A serious agent platform needs both layers working at once: application-level isolation for what the agent's code is allowed to touch, and a disciplined, boring, unglamorous host patch process underneath it that nobody notices when it's working.

The patch-cadence lesson

Copy-Fail is a security advisory with a fairly narrow technical footprint. The management lesson attached to it is not narrow at all: container isolation is layered, and the host kernel is one of those layers whether or not anyone is watching it. Patch the kernel first. Upgrade the engine where the kernel patch is not yet available. Review the profiles you inherited rather than assuming they were correct when someone else set them. Then test against the real workload, not a clean one. Netics can help review a Linux and container hardening path.

Sources

[1] https://developers.googleblog.com/build-zero-trust-ai-agents-with-googles-agent-development-kit — Google Developers Blog — Build zero-trust AI agents with ADK [4] https://www.docker.com/blog/mitigating-cve-2026-31431-copy-fail-in-docker-engine — Docker — Mitigating CVE-2026-31431 Copy Fail

Source: Docker Engineering — 2026-05-27. Netics analysis.