Copy Fail: The Optimization Was The Cover-Up
- Patrick Duggan
- 3 hours ago
- 4 min read
CVE-2026-31431 — Copy Fail — was added to the CISA KEV catalog on May 1, 2026 with a federal-civilian remediation deadline of May 15. CVSS 7.8. Local-user to root on every major Linux distribution. A 732-byte Python script is the exploit. There is nothing exotic about it. It's a logic bug in the AEAD socket interface of the kernel's userspace crypto API (algif_aead in the AF_ALG subsystem), and it has been there since 2017.
That last fact is the story.
Nine Years In The Tree
The bug was introduced in 2017 by commit 72548b093ee3 — an in-place optimization to AEAD encryption that lets the cryptographic authenticated-encryption-with-associated-data path use the caller's destination buffer as a scratch pad during operations. The performance argument was clean: avoid a copy on the hot path, save cycles on every encrypt/decrypt that runs through algif_aead. The kernel accepted the optimization. Every distribution downstream picked it up. Every container, every cloud workload, every shared CI runner that's been running a kernel newer than 2017 has shipped with this code path active.
The flaw is that the in-place optimization writes four controlled bytes past the legitimate output region and fails to restore them. The authenc(esn(*)) algorithm template uses the caller's buffer as a workspace, then doesn't clean up after itself. From userland, those four bytes become a primitive an unprivileged process can shape into anything it needs — including writing into kernel structures it shouldn't be able to touch. The 732-byte Python proof-of-concept walks that primitive into root reliably.
This was in the kernel for nine years. Through the audits. Through the static analysis. Through the fuzz farms. Through the tens of thousands of eyes that read kernel patches for a living.
The Optimization Was The Cover-Up
Calling Copy Fail a "bug" is generous. The vulnerability is not a typo or a missed bounds check on an obscure path. It's the optimization itself. The performance win that made it desirable is the same mechanism that made it exploitable — re-using the caller's buffer to skip a copy is exactly what produces the four-byte spillover. The shape of the optimization and the shape of the bug are the same shape.
That's what makes this case a cover-up rather than a regression. Nobody concealed a known flaw. The optimization was reviewed and accepted on its merits. The merits were real — the perf win was measurable. But the perf-win shape is identical to the leak shape, and for nine years no one in the disclosure pipeline drew that line. The optimization functioned as cover. The bug hid inside its own justification.
Compare to the PURSUE release we wrote up this weekend — there the curation was the cover, padding 22 real disclosures inside 162 records and counting each piece as new. Different surface, same architectural pattern. The thing that's supposed to make the system better is the thing that makes the system fail. The framing is the failure.
What This Means For Defenders
Every Linux kernel newer than 2017 is affected. That's almost every server you operate. Multi-tenant cloud, shared CI, container hosts where the non-root user was a security boundary you depended on. That boundary is now a 732-byte Python script.
Patch versions are 6.18.22, 6.19.12, and 7.0. KernelCare livepatch is available without reboot for distributions that ship it. Ubuntu 26.04 (Resolute) and later are not affected.
The fix is three upstream commits, not just a revert of the original in-place optimization. The optimization had downstream dependencies. The cleanup is bigger than the bug area, which is consistent with our point above — the bug shape is the optimization shape, so the fix has to touch every place that shape was relied upon.
The exploit is local-user-to-root, not remote. That sounds reassuring until you remember that every container with a non-root user, every CI runner that processes external repositories, every shell account on a shared host, every nested-VM workload is now a one-step privilege escalation away from kernel-level access on the host. In a cloud-tenant context this becomes a tenant-isolation question. In a CI context it becomes a supply-chain question.
Detection on disk is straightforward — kernel version inventory against the patched-versions list. Any kernel between 4.10 (where the original commit landed) and the patched releases above is vulnerable.
Detection on the wire is harder. The exploit is local. There are no C2 callbacks, no network signature, no domain to block. The detection surface is the host telemetry and the kernel-version inventory.
The federal civilian deadline is May 15. For everyone else, the realistic deadline is whenever your CI runner picks up its next dependency.
The Index Position
CVE-2026-31431 is in our cisa_kev index. The DugganUSA STIX feed reflects the KEV add. Our index now exposes kev_listed as a filterable attribute on the iocs index — you can pull the KEV-tied corpus in one query. This is the kind of thing the feed is for: when an LPE that breaks every Linux box on earth lands on KEV with a two-week federal deadline, the question for a defender is "what's already in my environment and on the patch clock," not "is there a fancier name for the threat actor." The patch clock is the threat actor.
The 95% epistemic cap applies. The technical writeup above is based on the public Microsoft, Ubuntu, Palo Alto Unit 42, and Red Hat advisories plus the original disclosure on April 29, 2026. Specific exploitation in the wild has not been confirmed by us against any customer environment as of this writing. The KEV listing implies CISA has confirmed exploitation in some environment; the typical signal is "ransomware actors weaponized it within hours of public PoC release," which is consistent with how the 2024 in-the-wild Linux LPEs played out.
Patch this week. Rebuild your container base images this week. Inventory your kernel versions across cloud, CI, edge, and dev. The optimization was the cover-up, the patch is the fix, and there is nothing on this side of the disclosure that excuses sitting on it.
— Patrick Duggan, DugganUSA LLC
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.




Comments