loading…
[OK] dns resolved
[OK] tcp handshake
[..] waiting on payload
Docker published a useful post this week on mitigating CVE-2026-31431, “Copy Fail” in Docker Engine. The short version: Copy Fail is a Linux kernel vulnerability in the AF_ALG crypto socket path, public exploit code landed before every distribution had kernel fixes ready, and Docker Engine had to move quickly because containers could still reach the vulnerable kernel surface from inside the default sandbox.
That sentence is doing the usual container-security magic trick: making “default sandbox” sound simpler than it is. Containers are not one wall. They are drywall, studs, wiring, plumbing, and one suspiciously load-bearing TODO comment.
According to Docker, Copy Fail affects the Linux kernel’s AF_ALG crypto subsystem and can let an unprivileged user perform controlled writes into the page cache. Because the page cache is shared by the host, the impact is not neatly contained inside one container. A process inside a default container that can create AF_ALG sockets may be able to influence what other processes on the host or in other containers read from shared files and image layers.
The real fix is a patched kernel. Docker is explicit about that. But the operational problem was timing: some distributions did not have kernel patches ready when disclosure and exploit availability created an immediate window of exposure. For many operators, updating Docker Engine was the faster mitigation path than waiting for a kernel package and reboot plan.
Docker first shipped Engine v29.4.2 with a seccomp hardening change that blocked AF_ALG sockets and also blocked the legacy socketcall(2) multiplexer. That helped close one path, but it broke networking for some 32-bit workloads. The Docker Engine 29 release notes describe the follow-up in v29.4.3: replace the broad socketcall(2) seccomp deny with targeted AppArmor and SELinux rules that block AF_ALG at the Linux Security Module layer, while keeping direct socket(AF_ALG) filtering as defense in depth.
The detail that matters: seccomp sees syscall arguments at the boundary. With socketcall(2), the relevant details are tucked behind a userspace pointer, so seccomp cannot selectively say “no AF_ALG, but yes normal sockets.” AppArmor and SELinux operate later, at the kernel object-creation hook, where the actual socket family is visible. Different layer, different leverage.
Docker’s fix is backed by the implementation trail too: the moby/profiles AppArmor change adds deny network alg, to the default container profile, and the 29.4.3 release notes call out the SELinux alg_socket mitigation and the need for selinux-enabled: true on SELinux systems.
This is not just “patch Docker.” You should patch Docker, but that is the least interesting lesson.
The more useful lesson is that container isolation is an interaction between kernel behavior, runtime defaults, LSM policy, seccomp profiles, distribution packaging, workload compatibility, and how quickly you can roll all of that out without setting your platform on fire.
A few practical takeaways:
Runtime updates are part of vulnerability response. Kernel CVEs often land in the runtime’s blast radius before the runtime is technically “vulnerable.” Docker says this did not compromise Docker infrastructure, but Docker Engine’s default profiles prior to v29.4.3 allowed the syscall surface the exploit used. That distinction matters for CVE ownership. It matters less at 2 a.m. when a host still has exposed workloads.
Seccomp is powerful, but not omniscient. It is a syscall-boundary tool. If the thing you need to decide is hidden behind a pointer or multiplexed interface, you may need LSM enforcement instead. This is exactly the kind of boring systems detail that ruins clean architecture diagrams, which is how you know it is important.
Compatibility is a security constraint. Docker’s first mitigation broke real 32-bit workloads, including cases reported in moby/moby#52506. Security controls that silently strand legacy workloads create rollback pressure. Rollback pressure creates exposure. Exposure creates meetings. Nobody wins, except the calendar.
Your host hardening posture changes the answer. On AppArmor-heavy distributions, the updated default profile can block AF_ALG through both socket(2) and socketcall(2). On SELinux systems, Docker notes that enforcement requires the daemon to run with selinux-enabled: true. On hosts without an effective LSM path, the remaining mitigation story is weaker until the kernel is patched.
If you run Docker Engine on Linux hosts, the operational checklist is straightforward:
v29.4.3 or later if you have not already.selinux-enabled: true as Docker’s release notes require.af_alg / algif_aead when those kernel modules are loadable and using a custom seccomp profile for the direct socket path.Do not stop at checking a version string in a spreadsheet. Test a representative workload after the runtime update, especially if you still have 32-bit binaries, game server tooling, Wine, SteamCMD, or other compatibility-shaped fossils running in containers.
The source details here come primarily from Docker’s own technical write-up and release notes. Docker has direct implementation context, but it is still one vendor’s account of a fast-moving vulnerability response. The durable fact is simpler: the kernel needs patching, and runtime-level mitigation is a bridge, not a cure.
Also, the exact exposure varies by kernel version, distribution patches, runtime configuration, and whether AppArmor or SELinux is enabled and enforcing. Treat “Docker Engine v29.4.3 or later” as a meaningful mitigation milestone, not a magic blessing from the container gods.
The bigger pattern is worth keeping: when a kernel bug crosses the container boundary, your security posture is only as strong as the layers that actually line up. Defaults help. Verification helps more.