CVE-2026-31431 is a Linux kernel vulnerability that was recently disclosed. This CVE does not compromise Docker infrastructure.<\/p>\n
That said, Docker Engine\u2019s default profiles prior to v29.4.3 allowed containers to create AF_ALG sockets, which is the syscall surface the exploit uses. You are not exposed if you are running Docker Engine v29.4.3 or later, OR a patched host kernel.<\/strong> If either of those is missing, you have exposure on that host, and you should read the rest of this post.<\/p>\n As of writing, the kernel patch is available on Debian (CVE-2026-31431<\/a>) and RHEL 9 (RHSB-2026-002<\/a>) but not yet on Ubuntu<\/a>. For users on distros that haven\u2019t shipped a kernel fix, upgrading Docker Engine is the mitigation you can apply today.<\/p>\n This CVE drew a lot of attention because the exploit became public before many Linux distributions had kernel patches available. As a result, most distros were still vulnerable and had no ready fix at the time of disclosure. It was especially notable because the bug affected Linux kernels going back to around 2017, making the potential impact unusually broad.<\/p>\n On the Docker Engine team, I started investigating what we could do from our end to protect users on vulnerable hosts. It turned out the mitigation was more involved than it first looked, and the first attempt broke 32-bit binaries. This post is what we shipped, what broke, what we learned, and where things stand now.<\/p>\n On April 29, researchers disclosed CVE-2026-31431, dubbed \u201cCopy Fail,\u201d a privilege escalation vulnerability in the Linux kernel\u2019s AF_ALG crypto subsystem.<\/p>\n The flaw is in the The exploit is trivial and works on every unpatched Linux kernel shipped since 2017.<\/p>\n The correct fix is a kernel update. The mitigations described below reduce exposure for containers running on unpatched kernels, but they do not fix the underlying vulnerability. If your kernel vendor has released a patch, apply it.<\/p>\n Inside a container running with default security profiles, an attacker with code execution can use Copy Fail to corrupt pages in the page cache. One possible outcome is escalating to root inside the container by corrupting setuid binaries.<\/p>\n But the page cache is shared across the host, so the impact is not confined to the attacker\u2019s container. Modified pages are visible to the host and to every other container that maps the same file, including shared image layers. Other workloads on the same node can be affected.<\/p>\n The attack does not require any special capabilities or privileges beyond what a default container provides. The only requirement is the ability to create an We updated Docker Engine\u2019s default seccomp profile<\/a> to block Blocking There is another way to create sockets on Linux: The problem for seccomp is that Linux 4.3 already added direct socket syscalls for i386 and s390, so we assumed most modern binaries would already use the new The Older versions of glibc on i386 route all socket operations through Blocking And this is not just an i386 problem. On amd64, any process can switch into ia32 compatibility mode with Affected containers could work around this by using a custom seccomp profile<\/a> that re-enables But that just pokes a hole in the hardening for those containers, since an attacker inside them could still reach The fundamental problem is that seccomp operates at the syscall boundary, and AppArmor and SELinux operate on a different level. Linux Security Modules hook directly into the kernel\u2019s In v29.4.3 (release notes<\/a>), we:<\/p>\nWhy you should read about Copy-Fail<\/strong><\/h2>\n
What Copy Fail is<\/strong><\/h2>\n
algif_aead<\/code> module. It allows any unprivileged user with access to an AF_ALG socket to perform controlled writes to the page cache. Since the page cache backs file reads across the entire system, an attacker can temporarily modify the contents of any readable file as seen by every process on the host. Corrupting a setuid binary is the most direct path to local root, but the primitive itself is more general.<\/p>\nWhat does this mean for containers?<\/h2>\n
AF_ALG<\/code> socket, which was previously allowed by Docker\u2019s default security profiles.<\/p>\nFirst attempt: seccomp (v29.4.2)<\/strong><\/h2>\n
AF_ALG<\/code> sockets. The seccomp filter inspects the first argument to socket(2)<\/code> and denies address families AF_ALG<\/code> and AF_VSOCK<\/code> (which was already blocked).<\/p>\nsocket(2)<\/code> is not enough on its own. There is another way to create sockets on x86_64 Linux: socketcall(2)<\/code>, an older multiplexed syscall that wraps socket<\/code>, bind<\/code>, connect<\/code>, and other socket operations behind a single syscall number.<\/p>\nsocketcall(2)<\/code><\/a>, an older multiplexed syscall that wraps socket<\/code>, bind<\/code>, connect<\/code>, and other socket operations behind a single syscall number.<\/p>\nsocketcall<\/code> packs the real arguments (including the address family) into a userspace array and passes a pointer, which BPF cannot dereference and inspect. There is no way to selectively block AF_ALG<\/code> through socketcall<\/code> with seccomp.<\/p>\nsocket<\/code> syscall and that socketcall<\/code> would only matter for old binaries. So we blocked it entirely and shipped Docker Engine v29.4.2 (release notes<\/a>).<\/p>\nWhat broke<\/h2>\n
socketcall<\/code> deny turned out to be too broad.<\/p>\nsocketcall<\/code>, the Go runtime uses it unconditionally for GOARCH=386<\/code> (independent of glibc), and many legacy and gaming workloads (SteamCMD, Wine) depend on it.<\/p>\nsocketcall<\/code> broke networking for a lot of 32-bit binaries running inside a container (moby\/moby#52506<\/a>).<\/p>\nint $0x80<\/code> and invoke socketcall<\/code> directly, bypassing the socket(2)<\/code> arg filter entirely. You do not need a 32-bit container or a 32-bit binary to reach that path.<\/p>\nsocketcall<\/code> while keeping AF_ALG<\/code> blocked for the direct socket(2)<\/code> path.<\/p>\nAF_ALG<\/code> through socketcall<\/code>.<\/p>\nSecond attempt: LSM-based enforcement (v29.4.3)<\/strong><\/h2>\n
socketcall<\/code> multiplexes many operations behind a single syscall number with pointer arguments. You cannot selectively block AF_ALG<\/code> through socketcall with seccomp alone.<\/p>\nsecurity_socket_create()<\/code> callback, which fires when the kernel actually creates the socket object, regardless of which syscall entry point was used. An LSM can deny AF_ALG<\/code> specifically while leaving all other socketcall usage intact.<\/p>\n\n
socketcall<\/code> seccomp deny<\/strong> to restore 32-bit compatibility.<\/li>\ndeny network alg,<\/code> to the default AppArmor profile<\/strong> (moby\/profiles#22<\/a>).
On systems with AppArmor enabled (e.g. Ubuntu, Debian), this blocks AF_ALG<\/code> through both socket(2)<\/code> and socketcall(2)<\/code>.<\/li>\n
The module denies alg_socket<\/code> creation for all container_domain<\/code> types and can be loaded via semodule<\/code>.
SELinux enforcement requires the daemon to be running with --selinux-enabled<\/code>.<\/li>\nsocket(AF_ALG)<\/code> arg filter<\/strong> as defense-in-depth for the direct socket(2)<\/code> syscall path.<\/li>\n<\/ol>\nWhat you should do<\/h2>\n
\n
This is the real fix.
Check with your distribution for a kernel update that addresses CVE-2026-31431.<\/li>\n