Linux Copy Fail grants root access

Linux kernel bugs usually stay abstract until somebody shows the ugly part — root access from an ordinary user account. That is what happened here. “Copy Fail,” tracked as CVE-2026-31431, is a local privilege-escalation flaw in the kernel crypto stack, and it went from private report to public exploit very quickly. The practical takeaway is simple: if an attacker can run code as a normal user on a vulnerable box, they may be able to become root. (bleepingcomputer.com) ### What actually broke? The bug sits in `algif_aead`, a Linux kernel interface tied to AEAD cryptography through AF_ALG sockets. The short version is that the kernel mishandles a copy operation, so a few bytes land outside the intended buffer. That sounds tiny — four bytes, in the public descripti(bleepingcomputer.com)upt state the kernel trusts. (howtogeek.com) ### Why does four bytes matter? Because this is kernel space, not a text file. Four stray bytes in the wrong spot can be enough to flip a pointer, alter bookkeeping, or poison cached data that later gets treated as legitimate. That is basically why bugs with microscopic writes can still become full privilege escalation chains. Theori’s w(howtogeek.com)o turn the primitive into working root exploits. (bleepingcomputer.com) ### Why are so many distros exposed? The vulnerable code path appears across a wide range of Linux distributions and kernels shipped over multiple years. Ubuntu marked the issue as high priority and described it as a trivial local privilege escalation, while Debian’s tracker shows active advisories(bleepingcomputer.com)ntical, but because the operational problem is similar: lots of ordinary Linux installs may be vulnerable until patched. (ubuntu.com) ### Was this really found with AI? Theori says yes — the flaw was discovered using its AI-assisted offensive security tooling, Xint Code, after scanning the Linux crypto subsystem. That detail matters less than the result, but it does show where vulnerability research is heading. The more immediate issue is that once the bug became public on April 29, 2026, exploit code an(ubuntu.com)ling lists. (bleepingcomputer.com) ### Who should worry first? Multi-user Linux systems. Shared servers. Developer workstations. University boxes. CI runners. Containers with a path to local code execution. The bug is “local,” which means an attacker usually needs some foothold first, but that bar is not very comforting if you alrea(bleepingcomputer.com)guidance treats patching as the main fix, not a nice-to-have. (ubuntu.com) ### Can you mitigate before patching? There are mitigations, but they are not as clean as updating. Discussion on oss-security points out that disabling or constraining AF_ALG use can have userspace side effects, because real software depends on it — things like `cryptsetup`, `bluez`, `iwd`, and software using `libkcapi`. So the catch is that temporary(ubuntu.com)tures. (openwall.com) ### What should admins do now? Patch first. Then verify kernel versions actually changed on running systems — especially on hosts that need a reboot to load the fixed kernel. After that, treat recent unexplained local activity with more suspicion than usual, because public PoCs are already out. If you run older or unsupported releases, the risk is worse, si(openwall.com)tatus. (ubuntu.com) ### Bottom line This is not a remote worm, but it is the kind of Linux bug defenders hate — broad exposure, easy local escalation, and public exploit code almost immediately. If a vulnerable machine gives an attacker a normal account, Copy Fail may do the rest. (howtogeek.com)