Copy Fail: Patches Are Coming. Here's What to Do Until They Land.

732 bytes of Python is enough to root every major Linux distro shipped since 2017.

That is the short version of CVE-2026-31431 ("Copy Fail"), disclosed this week by Theori. Ubuntu, RHEL, Amazon Linux, SUSE, kernels 6.12 through 6.18. No race conditions, no per-distro offsets, no compiled payloads. The bug has been sitting in the kernel for nine years. The full writeup is worth reading, even if it is a little AI-heavy.

Every security feed this week will tell you to patch your kernels. That advice is correct.

It is also incomplete for most of the organizations we work with.

The patch window is a thing

For a lot of teams, "patch now" describes an outcome, not a calendar event. Federal and regulated environments operate on change cycles measured in weeks. Production fleets need staged rollouts and reboot windows. Some organizations are still running long-lived kernels under STIG baselines that lag mainline by six months on a good day. Red Hat has rated this "Moderate" and marked the fix as deferred. If your distribution vendor is not racing, your fleet certainly is not either.

The disclosure process itself contributed to this gap. Distro vendors report they were not adequately notified about the nature of the vulnerability. The kernel patches landed April 1st with generic commit messages about reverting an optimization. Distribution security teams had to guess the actual impact from reading the code changes. Most vendors upgraded their severity assessments only after the public disclosure made the scope clear.

This notification breakdown cascades through the vendor ecosystem. When Red Hat rates something "Moderate," that signal flows to F5, Palo Alto, Cisco, and other vendors who build security appliances on Linux distributions. Enterprise customers running BIG-IP, PA firewalls, or Kubernetes clusters inherit the same delayed urgency assessment. The information gap multiplies across each layer of the stack.

The operational question is not whether to patch. It is what to do in the gap between disclosure and rollout.

The 30-second mitigation

The Copy Fail attack surface is the kernel's algif_aead module, which exposes the AEAD crypto interface to userspace via AF_ALG sockets. Disable that module and the exploit primitive disappears. No kernel update required, no reboot.

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

rmmod algif_aead 2>/dev/null || true

Two lines. Reversible. Survives reboot. For the vast majority of server workloads this changes nothing observable. dm-crypt, LUKS, kTLS, IPsec, OpenSSL, SSH, and TLS termination at scale use the in-kernel crypto API directly, not the userspace AF_ALG socket.

If something in your environment does rely on AF_ALG, check with lsof | grep AF_ALG or ss -xa before deploying. Test on a representative host first. For systems where algif_aead is built into the kernel rather than loaded as a module, the kernel parameter initcall_blacklist=algif_aead_init provides an alternative mitigation path.

The container question

Copy Fail is also a container escape primitive. The Linux page cache is shared across processes on a host, including across container boundaries. A compromised tenant on a shared kernel can corrupt setuid binaries visible to every other tenant and to the host.

For Kubernetes nodes and multi-tenant container platforms, the modprobe mitigation on the host removes the attack surface for every workload running on that node. A seccomp profile blocking AF_ALG socket creation is a reasonable runtime layer to keep in place even after the kernel patch lands.

File integrity tools will not catch this

Worth a separate note. The exploit corrupts the in-memory page cache and never touches the on-disk file. Tooling that compares on-disk hashes against a baseline will report no anomaly while a corrupted /usr/bin/su loads from cache and runs as root. If your detection strategy depends on file integrity monitoring, this CVE is a useful reminder of what that strategy does and does not cover.

The point

Patch when patches reach your fleet. That is still the destination.

"We are waiting for the maintenance window" should not be the same conversation as "we have no controls in place." The mitigation here is cheap, reversible, and removes the exploit primitive entirely. Document it in a ticket, deploy it through your config management of choice, and patch on whatever schedule your change board allows.

The interesting CVEs are the ones that force a workload audit. This is one of them.

What Now?

Patches are the destination. Mitigation is the bridge. But knowing which mitigations actually work in your environment—and which standard detection tools go blind—requires digging deeper than vendor bulletins.

Tailwind's full Copy Fail advisory covers the operational details vendor advisories skip: why file integrity monitoring fails, which container isolation actually holds, and the triage steps that work during your patch window. Enhanced analysis for teams that need more than "patch now."