'Copy Fail' lets a 732-byte script grab root on Ubuntu, RHEL, and SUSE. Patched April 29.

Xint Code published “Copy Fail” on April 29 with a 732-byte exploit. The Python script lifts any unprivileged user to root on Ubuntu 24.04, RHEL 10.1, SUSE 16, and Amazon Linux 2023 by chaining a nine-year-old kernel crypto bug into a 4-byte write that bypasses every file-integrity tool you have.

The vulnerability is CVE-2026-31431, a logic flaw in the kernel’s authencesn AEAD wrapper that’s been live since the 2017 in-place optimization for algif_aead. The exploit doesn’t race, it doesn’t need kernel offsets, and it doesn’t dirty the file on disk. The same script works across distros without modification, which is the part the kernel security team called out as unusual when it accepted the patch on April 1.

What we know

The bug has been latent in the kernel since commit 72548b093ee3 in 2017, which added an in-place mode to algif_aead for performance. Xint’s write-up walks through how the optimization assumed something the AEAD wrappers don’t guarantee, and how nine years of kernel work since then quietly stacked the primitive into a cross-distro local-root.

• Disclosure timeline. Xint reported the bug to the kernel security team on March 23, 2026. Patches landed in mainline on April 1. The CVE was assigned April 22 and the public write-up went live April 29.
• Root cause. The authencesn AEAD template uses the caller’s destination buffer as scratch space. With algif_aead’s in-place mode, the scratch write can land 4 bytes past the legitimate output, into the next chained scatterlist entry. If that entry is a page-cache page, the write modifies cached file contents.
• Target. The released exploit overwrites the cached version of /usr/bin/su to graft a shellcode shim. Because the file on disk never changes, AIDE, Tripwire, dm-verity, and most EDR tools see a clean state.
• Tested kernels. Ubuntu 24.04 LTS (6.17.0-1007-aws), Amazon Linux 2023 (6.18.8-9.213.amzn2023), RHEL 10.1 (6.12.0-124.45.1.el10_1), SUSE 16 (6.12.0-160000.9-default). Anything older with algif_aead is presumed vulnerable.
• Patch. Mainline commit a664bf3d603d reverts the 2017 in-place optimization. Distros are shipping backports this week. The commit message is blunt about the original mistake: “There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings.”
• Discovery. Xint Code’s blog post credits Taeyang Lee at Theori with the initial insight, and an in-house AI-assisted vulnerability scanner with the full exploit chain.

What we don’t know

A few things the public disclosure deliberately leaves open. Xint Code held the exploit while the patches landed, so the timeline of “did anyone find this independently” is not yet on the record.

• Field exploitation. No public IOC. Page-cache modifications don’t leave artifacts on the filesystem, so historical detection at scale is hard.
• CVSS. No score on the NVD record yet. Local privilege escalation with no user interaction and high reliability typically lands above 7.0.
• Container blast radius. The shared host page cache means a container with AF_ALG access can in principle modify a binary another container will execute. Whether that path was used in the wild is unknown.

What this means for you

If you run Linux on hardware you control, the only correct response is to take the kernel update your distro is pushing this week. Ubuntu, Red Hat, SUSE, and Amazon Linux all have backports queued. Reboot is required: a userspace patch alone won’t fix a page-cache primitive.

For everything else, the mitigation worth deploying today is a seccomp filter that blocks socket(AF_ALG, ...) from any process that doesn’t legitimately need it. Most workloads don’t. Container hosts should disable the algif_aead module entirely (modprobe -r algif_aead, blacklist) until the host kernel ships the patch, because the page cache is shared across container boundaries on the same host.

Cloud customers running managed Kubernetes should ask their provider for a node-image refresh date in writing. AWS, GCP, and Azure all use derivative kernels, and “we’ll patch on our normal cadence” is the wrong answer for a deterministic local-root primitive that bypasses file integrity.