Copy Fail: 732-Byte Python Script Roots Every Linux Since 2017
Description
A branded vulnerability disclosure card titled 'Copy Fail' (with 'Fail' in blue) on a white background, in the style of marketed CVE landing pages. The text reads: 'Most Linux LPEs need a race window or a kernel-specific offset. Copy Fail is a straight-line logic flaw - it needs neither. The same 732-byte Python script roots every Linux distribution shipped since 2017.' Below in smaller grey text: 'One logic bug in authencesn, chained through AF_ALG and splice() into a 4-byte page-cache write - silently exploitable for nearly a decade.' The image highlights a local privilege escalation in the Linux kernel crypto stack (authencesn via the AF_ALG userspace crypto socket API), chained with splice() to achieve a page-cache write, notable for being deterministic - no race condition or per-kernel offsets required - and for affecting nearly a decade of kernels with a tiny universal exploit
Comments
26Comment deleted
A decade of KASLR, stack canaries, and lockdown LSMs, defeated by a logic bug small enough to fit in a commit message
Linux achieved zero-copy so efficiently it also zero-copied the permission check.
Any non-AI summary? Comment deleted
quote form the official site: What is Copy Fail in one sentence? An unprivileged local user can write 4 controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root. Comment deleted
I'll say that the official website overhypes it a bit; you need a specific kernel module loaded from what I can tell. From what I know in my circle of friends, some are affected, others are not. and of course most people already got the patched kernels if they updated in the last week or 2 Comment deleted
so this mostly affects servers that can't easily reboot or hotswap kernels Comment deleted
this friend understands it better than I do https://social.hackerspace.pl/@q3k/116490249266904439 Comment deleted
also: something about "responsible disclosure" and "recent events" or something idk Comment deleted
Well-played NSA, well-played. Comment deleted
responsible disclosure is a myth by big security to sell more security Comment deleted
where responsible disclosure Comment deleted
https://www.openwall.com/lists/oss-security/2026/04/29/25 Comment deleted
got some more opinions from my friends: "none of the ~100 servers I admin are affected" as well as "the module was loaded and the exploit functional on all of my arch linux bare metal boxes." so there's a real split going down in the community here Comment deleted
"None are affected" or "None could complete the PoC test with hard-coded paths and pre-compiled binaries for x86"? Comment deleted
I believe the preventive measures themselves were efficient enough Comment deleted
being? Comment deleted
not anything specific, just no premise for that exploit Comment deleted
you basically only need an unpatched kernel, that's it Comment deleted
it's the target. The premise is some malware backlog or user with malicious intent Comment deleted
that doesn't mean "not affected" tho Comment deleted
affected - the necessary kernel module isn't loaded Comment deleted
There additional chains to widely increase blast radius that were not made public - it’s stated by author and there’s no actual reason to not believe it Comment deleted
well. but those are yet to be patched, so I consider them to be separate CVEs, no? Comment deleted
meaning, based on this same exploit Comment deleted
but the exploit relies entirely on this kernel module. the out-of-bounds access was entirely in that kernel module Comment deleted
as far as I understood at least Comment deleted