Docker Engine and Copy Fail: what to update if the kernel patch has not landed

Hook

Docker often feels like just another layer in the stack that needs to stay current. Copy Fail made that feel much more concrete: if the host kernel patch is still missing, Docker Engine can give you a fast temporary reduction in exposure while your distro is catching up.

This is not a story about “everything is broken”. It is about a narrow but real risk window on Linux hosts running containers. On May 27, 2026, Docker described CVE-2026-31431 as a Linux kernel issue and explained that older Docker Engine default profiles allowed containers to create AF_ALG sockets, which is the surface the exploit uses. So Docker is not the root cause, but it was one of the fastest places to reduce exposure.

What actually happened

CVE-2026-31431, also called Copy Fail, is a Linux kernel vulnerability tied to the AF_ALG crypto subsystem. In plain terms, an attacker who already has code execution inside a container can use this path to affect the page cache. The page cache is shared across the host.

That is the part that makes this different from a simple “one bad container” issue. If cached pages are modified, the impact can spill into other processes on the same host, other containers, and even shared image layers. In other words, the problem is not confined to a single workload.

Docker says the key point clearly: the correct fix is a kernel update. Everything else only reduces exposure until your distro ships the real patch.

Why this matters for ops teams

For a casual reader this looks like another CVE. For anyone running prod or staging on a Docker host, it means something more practical:

• if the kernel is still unpatched, container restrictions become part of your defense;
• if Docker Engine is old, you lose one of the quickest ways to shrink the window of risk;
• if you try to “fix” it with seccomp=unconfined, you are removing another protection layer instead of solving the issue.

The Docker release notes show the actual path of the mitigation. In 29.4.2, Docker blocked AF_ALG sockets and socketcall(2) through seccomp, but that broke some 32-bit workloads and i386 images. In 29.4.3, Docker removed the overly broad socketcall deny and moved the protection into AppArmor and SELinux so both socket(2) and socketcall(2) paths are covered without breaking legitimate 32-bit use cases.

What to do today

1. Check whether you are exposed

Start by checking the host kernel and Docker versions:

uname -r
docker version
docker info

If your distro has already shipped the kernel fix, that is the best outcome. If not, keep going, but do not sit on it.

2. Patch the kernel first

This is the real fix. Docker states directly that the Engine mitigation does not replace the kernel patch. If your vendor has already published an update, that should be your first move.

That matters because the container mitigation does not remove the vulnerability from the system. It only reduces the chances that a container can reach the dangerous path while the kernel is still vulnerable.

3. Upgrade Docker Engine to 29.4.3 or later

This release is where the balance between security and compatibility landed. It:

• blocks AF_ALG through AppArmor / SELinux;
• keeps seccomp as defense in depth;
• avoids the 32-bit breakage caused by the earlier attempt.

On SELinux-based hosts there is one extra requirement: selinux-enabled: true must be set in daemon.json or via the CLI flag. Without that, the SELinux mitigation will not behave the way you expect.

4. If you cannot upgrade the kernel or Engine right away

Do not invent a custom emergency that removes more protection than necessary. Docker’s docs describe a legitimate temporary path:

• use a custom seccomp profile for specific containers;
• in the 29.4.2 guidance, Docker pointed to seccomp/v0.2.1, which keeps AF_ALG blocked but restores socketcall compatibility;
• do not use --security-opt seccomp=unconfined as a shortcut.

If you run 32-bit binaries or old images, test them separately. That is where the surprises usually show up.

5. Restart the daemon and verify the change

After upgrading Engine, a daemon restart is usually enough; you do not need a host reboot just for the Engine update. But if you changed AppArmor profiles or SELinux settings, verify that those changes are actually active.

A minimal smoke check:

docker run --rm alpine uname -a
docker run --rm alpine sh -lc 'id && cat /etc/os-release'

Then run the workload that matters most to you, especially if it relies on old utilities, Wine, SteamCMD, or other 32-bit dependencies.

Anti-patterns

• Do not stop at a Docker upgrade if a kernel patch is already available.
• Do not use seccomp=unconfined as a quick fix.
• Do not assume 29.4.2 and 29.4.3 do the same thing.
• Do not leave SELinux mitigation half-configured and then assume the host is protected.
• Do not treat this as a single-container problem. A shared host means shared risk.

Bottom line

The safe order is:

1. install the kernel patch;
2. upgrade Docker Engine to 29.4.3+;
3. check AppArmor / SELinux behavior;
4. use a temporary workaround only for workloads that truly need it;
5. do not confuse mitigation with a full fix.

Copy Fail is a useful reminder that container runtime updates are not only about new features. Sometimes they are the fastest way to close a narrow but nasty risk window while the kernel patch is still on the way from the distro.

Sources

• Docker Blog: https://www.docker.com/blog/mitigating-cve-2026-31431-copy-fail-in-docker-engine/
• Docker Docs: https://docs.docker.com/engine/release-notes/29/
• Docker Docs 29.4.3 section: https://docs.docker.com/engine/release-notes/29/#2943