Linux Fail

Added: 2026-05-10

[00:00:00]A few months ago, I made a video about the mythology of Linux security.

[00:00:04]Remember where I said that this whole narrative of Linux is more secure was an exaggeration that the real advantage of Linux is transparency and the freedom to control what happens on your system, not some intrinsic magic that makes it immune to bugs. Obviously, that analysis attracted criticism. Someone even suggested I was doing Microsoft propaganda. Unpleasant but typical of certain circles where reality gets replaced by faith. Say Linux has vulnerabilities and someone accuses you of being a sabotur.

[00:00:36]Well, today I want to come back to this topic because perfect timing lets me make a very concrete analysis. A few weeks ago, a vulnerability was disclosed that describes exactly what I meant. a massive bug present for almost 10 years in the Linux kernel that nobody had noticed until two weeks ago. This vulnerability is called copy fail. It's designated CVE 2026 31431 and it allows any unprivileged user to become root in under a second on practically every Linux distribution since 2017.

[00:01:10]Before showing you the technical solution, let's explain how this hole works in a way that's understandable even if you don't have 10 years of kernel hacking behind you. When a program opens a file, whether it's the Sue executable, a library, a document, the kernel doesn't read the file directly from disk every time, that would be too slow. Instead, it loads the content into RAM into a structure called the page cache and gives the program a corridor to that memory. This is brilliant because if 10 programs read the same file, the kernel serves them all the copy from RAM, not from disk.

[00:01:43]First access loads the file into cache.

[00:01:46]Slow disk access. Subsequent accesses served from RAM extremely fast. All transparent, you don't even notice it happening. But I guarantee that if the kernel didn't work this way, your computer would be 10 times slower.

[00:02:00]Obviously to prevent a malicious user from modifying this cache and corrupting other people's files or worse the cache of seduid executables like sue the kernel enforces strict permission checks. The input cache should be read only. The output cache should be a separate protected area. This is where a hardware cryptography module implemented in the kernel comes in. ALGIF AAD AAD stands for authenticated encryption with associated data. an algorithm that encrypts and authenticates in a single operation. This module is a brilliant optimization. Instead of handing cryptography off to OpenSSL in user space, which is slow, you use the kernel directly, which can delegate the operation to your hardware crypto if available, extremely fast.

[00:02:46]Unfortunately, in one of these optimizations, someone made a microscopic logic error, literally four bytes at a time, that allows bypassing all permission checks on the page cache.

[00:02:57]How does it work in practice? Imagine an innocent text file utx.txt. The exploit wants to corrupt the cache of this file with arbitrary content chosen by the attacker. First, you open the file.

[00:03:09]Utx.txt gets loaded into the page cache.

[00:03:12]All normal. Then you fake the cryptographic input. You take the file content and pretend to pass it to the algif AED module as if it were encrypted data you want to decrypt. But here you also inject your malicious payload, stole four bytes at a time. Because of the bug in the internal HMAC calculation, the algorithm writes your payload directly into the files cache, completely bypassing the permission checks. You repeat four bytes at a time until the entire cache contains what you wanted. When you read the file, the cache is corrupted and the kernel serves you the falsified version. Now applying this to serious targets, the same technique works on sue substitute user which is a set to root executable.

[00:03:56]Meaning when you run it even as a normal user, the code runs with root privileges. Corrupt the sue cache so its code doesn't ask for a password and doesn't do any checks. Then run it boom your root without guessing any password without any initial privilege beyond the ability to run a Python script. How do you know if your system is vulnerable?

[00:04:17]On the official exploit site link in the description, there's a test command that doesn't damage your system. It runs the exploit but without actually becoming root. Just run python 3 copy fail check.py.

[00:04:31]If you see the normal user prompt turn into a root prompt, you're vulnerable.

[00:04:34]If it stays as user, you're already patched. The primary solution is to update your kernel to the latest version for your distribution. And I assume 99.9% of you know how to do that.

[00:04:46]Unfortunately, some vendors haven't released patches yet. Seuss, Red Hat, Ubuntu before 26004 still had vulnerable kernels at the end of May. In that case, you need to apply a temporary mitigation. Disable the ALGIF AEAD module. The workaround is two commands.

[00:05:02]The first creates a configuration file that tells the kernel if anything tries to load Algif AAD, refuse. The second removes it from memory immediately without waiting for a reboot. This module is rarely used by normal applications. Most apps use OpenSSL and user space. DMC, Lux, KTLS, IPSec, SSH don't need it. You might see some performance impact only if you're doing cryptography via AFG socket directly, which is very rare. If your DRO eventually releases the patch to get back to the original state, just delete that configuration file and reboot.

[00:05:36]After applying the mitigation, run the test again. If it fails, you're protected. I've also written a simple bash script that you can download from the link in the description. You run it with pseudo. It gives you a menu with four options. Check if your system is vulnerable. Apply the mitigation. Roll back the mitigation if your kernel gets patched later. And show a full system report with your kernel version, distribution, and current mitigation status. It works on any Linux distribution. Oh, and it has a little surprise at the beginning. Don't skip it.

[00:06:09]Now, many of you will ask, why publish such a devastating exploit before all distributions are patched? It's a good question, and the answer is far from obvious. There's a myth that security improves if bugs stay secret. This is the security through obscurity model.

[00:06:25]The theory that if nobody knows about the bug, nobody can exploit it. It doesn't work. Historically, it never works. Big bugs stay hidden for only a short time. They get discovered by governments, hacking agencies, criminals. Before long, the exploit is being used in real operations without normal users knowing anything about it.

[00:06:45]They think they're safe. They're not.

[00:06:49]Responsible disclosure has a wellestablished track record instead.

[00:06:52]The researcher finds the bug, privately notifies the vendor, and gives them time to patch, typically 30 to 90 days, and after the deadline publishes publicly.

[00:07:02]Why? Because transparency forces vendors to move fast. If they know the deadline is firm, they work to meet it. In this case, the disclosure arrived before distributions had patches ready. A shame, but the timing still serves to put pressure on vendors to move. A bug nobody knows about is a permanent backdoor in your system. A bug everyone knows about is an opportunity. CIS admins protect their systems. Auditors review their assets. Vendors prioritize the fix. The community shares mitigations. If copy fail had stayed hidden another 5 years, it would have been silently exploited by government agencies, criminals, anyone with access to a compromised machine. You'd know nothing. You'd think you were safe. Now instead, you know you can act. There is, however, a legitimate objection that has become relevant in recent years.

[00:07:53]Traditional responsible disclosure is showing its limits and AI is directly involved. Once when a bug was published, there was still a time window where only a few people knew about it. Disclosure served to wake up vendors and force them to move. Today, the calculation changes.

[00:08:09]Copy fail was discovered in 1 hour of scanning with an AI vulnerability scanner. 1 hour, no human fatigue, no lapse in attention. When an exploit becomes public, anyone can take the same approach, train it on the vulnerability and set it loose, scanning database code, router firmware, embedded system kernels in parallel at scale, lowering the technical barrier for anyone who wants to exploit it. This is the dark side of disclosure that the traditional model never really had to face. So what do we do? Keep bugs secret? Go back to security through obscurity?

[00:08:45]No. Because secrecy lasts even less than before. The same tools that found copy fail in an hour would find it anyway, regardless of whether it was published.

[00:08:53]And in the meantime, the bug stays silently exploited by whoever found it first. The real answer isn't secrecy.

[00:09:00]It's speed. Remediation windows measured in days, not months. Immediate coordinated pressure on vendors. The problem with copy fail was exactly this.

[00:09:10]The disclosure arrived when the major distributions didn't have patches ready.

[00:09:15]One more week of coordination would have made an enormous difference. I don't know what the right model for the future looks like. I only know that with AI lowering the cost of discovering and exploiting vulnerabilities, the current one doesn't hold up anymore. And this will be one of the central themes of information security in the coming years.

[00:09:35]Coming back to where we started, Linux is not magically secure. It's software.

[00:09:40]It has bugs. It has vulnerabilities just like Windows, Mac OS, and every other operating system. But there's something deeper worth saying clearly.

[00:09:49]The privilege model that Linux is built on, pseudo sue, administrator permissions granted wholesale across the entire machine, is showing structural cracks, not implementation cracks, design cracks. And copy fail is a perfect example. The problem isn't just the bug in Algif AD. It's that a normal user can corrupt the cache of a setued executable and become root because the model itself concentrates too much power in a single point.

[00:10:16]I'm not the one saying this. The people who invented Unix are. The very creators of Unix when given a blank slate to start over, designed plan 9, a system with a radically different permission model where privileges are granular, contextual, not concentrated. That's not a coincidence. It's a statement from people who understood the limits of what they had built.

[00:10:39]And pay attention because an important distinction needs to be made here. We're not talking about Unix as a design philosophy. The Unix philosophy, do one thing, do it well, compose the pieces, is solid, it's elegant, and it continues to produce excellent software. But we shouldn't confuse the philosophy with everything that has been built by applying it. The fact that something follows Unix's philosophy doesn't make it immune to time passing and technology advancing.

[00:11:07]And for the more malicious listeners out there, then system D is correct, right?

[00:11:13]Not exactly. It applies to every init system written after in it. Those that follow Unix's philosophy more or less faithfully, that work more or less excellently, often better than systemd, and that do one thing. The point isn't which in it you use. The point is that the underlying privilege model is the same for all of them and that's what's cracking. The real value of Linux remains transparency. When a bug is discovered, you can see it, understand it, mitigate it, and share it without having to beg a corporation to tell you whether you're vulnerable. But intellectual honesty requires that we also acknowledge the structural limits of the model, not just its strengths.

[00:11:52]See you in the next video. And as always, may Linux be with you.