Hacking, Code & Open Source Reads

Four Root Exploits in Three Weeks. Stop Blaming Linus

Christian Lehnert • 2026-05-16 • ~13 min read

Between April 29 and May 14, 2026, the Linux kernel ate four publicly-disclosed local privilege escalation or information-disclosure bugs. Copy Fail, Dirty Frag, Fragnesia, ssh-keysign-pwn. Working PoCs on GitHub the same day. CISA KEV listings. CERT-EU advisories. Every distribution you have ever shipped — Debian, Ubuntu, RHEL, SUSE, Alma, Amazon Linux — on the affected list.

And every blog post, Mastodon thread, and LinkedIn pundit converged on the same chorus inside 48 hours: Linux is broken. The kernel is unsafe. We need Rust. We need formal methods. We need fewer maintainers, or more maintainers, or younger maintainers, or AI-assisted review, or less AI-assisted review.

I want you to do something. Open a shell on your most precious production server — the one you would lie about under oath to keep running — and list the loaded kernel modules. Count them. Then ask yourself, honestly, how many of those modules you can name. How many you can justify. How many were loaded because some daemon you forgot you installed in 2021 reached for a syscall during boot and the kernel obligingly autoloaded whatever the syscall demanded.

If you cannot give a ten-second answer for every one of those modules, then the kernel is not your problem. You are.

The exploits, in plain language

Let me walk through what actually happened, because most of the writeups bury the embarrassment in marketing.

Copy Fail is a local user corrupting the page cache through the kernel's userspace crypto API — specifically a module called algif_aead, sitting behind the AF_ALG socket family. The attacker overwrites the in-memory copy of a setuid binary, executes it, gets root. The on-disk file stays untouched, so file-integrity monitoring sees nothing, your SIEM correlates nothing, and Tripwire goes back to sleep. CVSS 7.8. CISA added it to the Known Exploited Vulnerabilities catalog within 48 hours. The deadline for U.S. federal civilian agencies to remediate fell on the same day Fragnesia dropped, which I suspect was not a coincidence.

Dirty Frag is the same primitive — page-cache corruption — through a different door. This time it is the XFRM ESP modules used by the kernel-side IPsec data path, and rxrpc, a protocol that exists in 2026 almost exclusively to support OpenAFS clients. The mitigation was, and remains, blacklisting modules that the overwhelming majority of servers do not use, have never used, and will never use.

Fragnesia is the part of the story that should make you put your coffee down. The Dirty Frag patch landed. Diligent admins applied it. The Dirty Frag fix itself activated a previously-latent bug in a deeply internal socket-buffer function called skb_try_coalesce. The patch that was supposed to close the wound opened a new one. Same neighbourhood, same primitive, same root, different syscall path. Some patched kernels actually became more exposed than the unpatched ones, until the Fragnesia fix landed a week later. The admins who never used IPsec and had blacklisted those modules on principle were never exploitable in the first place. The admins who patched and didn't blacklist got owned by the patch. There is a lesson here, and it is not "patches are dangerous." It is "modules you do not need should not be loadable, ever, by any unprivileged process, under any circumstances."

ssh-keysign-pwn is the polite one of the four. It is not a page-cache write, it is an information disclosure: a six-year-old logic flaw in __ptrace_may_access that lets a local user race a SUID binary's exit window to steal its open file descriptors. Jann Horn drafted the fix in October 2020. The patch was never merged. Qualys re-reported the bug six years later and Linus committed the fix the same afternoon (commit 31e62c2ebbfd). The public proof-of-concept reads /etc/ssh/ssh_host_*_key via ssh-keysign and /etc/shadow via chage -l. So now an unprivileged user on your shared shell server has every password hash on the box for offline cracking and your SSH host identity for man-in-the-middle attacks against future connections. Not instant root, but a foothold that will turn into long-term compromise if you let it sit. One sysctl line — kernel.yama.ptrace_scope=3 — blocks the public PoCs entirely. Most admins do not have it set.

The common factor

Look at three of those four bugs and tell me what you see.

Copy Fail needs algif_aead. Dirty Frag needs esp4, esp6, rxrpc. Fragnesia needs esp4, esp6. These are not exotic modules. They are also not modules anyone on a normal Linux server actually uses.

Be honest with yourself. On the Debian or Ubuntu host you are operating right now, do you terminate IPsec tunnels in-kernel? Do you run an AFS client in 2026? Do you have any userspace process binding AF_ALG sockets to do AES-GCM in kernel space, when OpenSSL, GnuTLS, NSS, kTLS, dm-crypt, LUKS, and OpenSSH all already do their own crypto in userland on every system in your fleet? The honest answer is no. The honest answer for ninety-five percent of Linux servers in production is no. And yet on the kernel your distribution shipped you, every single one of those modules was loadable on demand by any process that knew the right socket(2) incantation. None of them required administrative action to become exploitable. They were autoloaded the moment the attacker reached for them.

That is not Linus's fault. It is not Greg Kroah-Hartman's fault. It is not the maintainer team's fault. It is the distribution's fault for shipping a kitchen-sink kernel where every optional subsystem is one syscall away from execution, and it is your fault for never auditing what your production servers actually need.

The exploits are not new. The negligence is.

The psychology of the lazy admin

There is a comfortable mental model in this profession, and it goes like this. The vendor ships a product. The vendor is responsible for the product's defects. The admin is responsible for applying the vendor's patches in a timely manner. The admin is therefore absolved of architectural responsibility, because architecture is the vendor's job. Patch Tuesday rolls around, the admin applies patches, the admin earns his salary.

This model works for proprietary appliances where the vendor genuinely is responsible for the security posture out of the box, and the admin's only knob is "update or don't." It does not work for Linux. It never has worked for Linux. The whole philosophical project of free software is that the user is responsible for the system, in exchange for the freedom to alter it. A Linux distribution is not a hardened appliance. It is a parts bin with sensible defaults. Sensible for whom is the question that distinguishes a senior admin from a junior one, and the answer is: sensible for the lowest common denominator of users, which is to say, sensible for nobody in particular.

When an admin runs a distribution kernel unmodified on a production server and then complains that "Linux had four CVEs in three weeks," what he is really saying is "I never read the documentation that came with the chainsaw, and I am surprised the chainsaw cut me." The chainsaw is fine. The chainsaw is doing exactly what chainsaws do. The mistake is upstream of the chainsaw. The mistake is that an adult with professional responsibility for the workload picked up the tool without learning what every switch on it does, and then ran it in the kitchen.

There is a particular smell to this kind of complaint. It is always phrased in the passive voice. The server got rooted. The kernel was vulnerable. The patch was delayed. Never I left a module loaded that I did not need. Never I ran a shared shell server on a general-purpose distribution. Never I architected this badly three years ago and now the bill has arrived. The passive voice is the linguistic tell of an admin who is mentally preparing to blame the upstream maintainers for his own choices, and you can hear it forming before he has even finished writing the post-mortem.

The wrong tool on critical infrastructure

Now we arrive at the part of the conversation nobody on Hacker News wants to have. A great deal of the Linux deployed on critical infrastructure in 2026 is the wrong Linux, run the wrong way, by the wrong admins, for the wrong reasons.

Debian and Ubuntu are extraordinary projects. I have run Debian for well over a decade, FreeBSD on multiple systems alongside it, and I contribute to Debian where I can. They are the right answer for general-purpose workstations, for development servers, for the homelab, for hobbyist hosting, for the small business with three VMs and an OPNsense box, for the university lab, for the CI runner pool, for the test environment. They are free, they are flexible, they have the widest hardware and software support in the industry, and they are maintained by volunteers and small companies operating on finite budgets.

They are not, and have never been, turnkey hardened platforms for critical infrastructure. They were not designed to be. The Debian release process is not the Red Hat security errata pipeline. The Ubuntu LTS kernel is not the SUSE Linux Enterprise Server kernel. The volunteer who maintains the package your hospital scheduling system depends on is not on the same pager rotation as the engineer whose paycheck depends on RHEL backports landing within hours of upstream disclosure. None of this is a criticism of Debian or Ubuntu. It is a description of what they are, written by someone who loves them and would not deploy them for the role too many shops are deploying them in.

If you are running a multi-tenant shared shell server on Ubuntu LTS, you are running the wrong product. If you are running a Kubernetes node that mixes customer workloads on a generic Debian kernel, you are running the wrong product. If you are running a public-facing CI runner that executes pull request code from strangers on the same kernel as your build artefacts, you are running the wrong product. If you are running an industrial control system or a hospital information system or a financial trading platform on the default kernel of a community-supported distribution because it was free and your boss did not want to pay for a support contract, you are running the wrong product. The published proof-of-concepts for Copy Fail and Fragnesia turn any of those scenarios into a single-command root by an unprivileged user. That is not a theoretical threat model. That is the actual exploit code on GitHub today.

The right products exist. For critical infrastructure where the SLA is measured in money lost per minute of downtime, the right product is Red Hat Enterprise Linux or SUSE Linux Enterprise Server with an active support contract, because the support contract is the actual product you are paying for. The kernel is the same kernel; the difference is that someone on a payroll is reading the upstream security mailing lists at three in the morning so that you do not have to, and is shipping backports to your fleet on a timeline that is contractually enforceable. For services where you want a kernel you can reason about, where the bug class that ate the Linux kernel three times in two weeks does not translate cleanly to a different VM subsystem and a different review culture, the right product is FreeBSD, deployed with jails and VNET. For multi-tenant code execution where you must run untrusted workloads on shared physical hardware, the right product is per-tenant microVMs, where the blast radius of a kernel exploit is bounded to a single tenant's VM and not your entire fleet.

The admin who runs Ubuntu LTS on the shared shell server, then complains when a kernel CVE lands and his shared shell server gets rooted, is not the victim of bad upstream code. He is the victim of his own architectural decisions, made three years ago, when he picked the cheapest and most familiar Linux for a workload that needed a different operating system entirely. The CVE is the bill arriving for that decision. Linus is not on the hook for it. Greg KH is not on the hook for it. The maintainer who reviewed the original commit in 2017 is not on the hook for it. The hook is in the admin's own back, where he put it.

What the senior admin does differently

The senior admin starts from the workload and works backwards to the operating system. He asks, before anything else, what this server actually has to do, and what the consequences are if it stops doing it, and what the consequences are if a stranger gets root on it. He matches the answer to the operating system, and the operating system to the distribution, and the distribution to the support contract, and only then does he start typing.

The senior admin treats the default kernel as a starting point for negotiation, not as a finished product. He audits the loaded modules, the autoload paths, the sysctl defaults, the namespace knobs. He blacklists everything the workload does not need. He restricts ptrace. He disables unprivileged user namespaces unless something genuinely depends on them. He does this once, in configuration management, and the configuration runs on every server he builds for the rest of his career.

The senior admin reads the release notes. He subscribes to the security mailing lists for his distributions. He treats kernel CVEs as architectural feedback, not as patch-and-forget tickets. When a vulnerability like Fragnesia surfaces — a bug born from the fix to a previous bug, in a subsystem the workload does not use — he does not feel surprised, because he is already not running that subsystem. He reads the post-mortem because he is curious, not because he is exposed.

The senior admin chooses the right operating system for the workload, even when the right answer is uncomfortable, even when it means writing a memo to management explaining why the new fintech platform needs a RHEL subscription instead of being thrown onto the existing Debian fleet, even when it means telling the developers that no, they cannot have a shared shell server, and yes, they have to use ephemeral containers, and yes, they will be unhappy about it for two weeks before they realise it is faster anyway.

The junior admin does the opposite of all of this and then writes a thread on social media about how Linux has become unreliable. The four exploits of the last three weeks have not made Linux unreliable. They have made it visible that a great many people who call themselves Linux administrators are doing approximately none of the things their job description implies.

The bill is due

The Linux kernel will ship more local privilege escalation bugs. The XFRM/ESP attack surface is not done — three deterministic page-cache primitives from one neighbourhood in fourteen days is a pattern, not a coincidence. AI-assisted auditing tools are now competitive with manual review, multiple security teams are running them, and they are pointed at every subsystem your kernel has ever loaded. You will read about the next one in two weeks, and the one after that two weeks later, and you should expect that cadence to continue for the foreseeable future.

The kernel will keep shipping bugs. That is inevitable. What is not inevitable is leaving every optional subsystem one socket() call away from execution on your production machines.

You cannot patch your way out of this if you keep treating the kernel as a black box that arrives in a known-good state. It doesn't. It never did. The vendor ships a chainsaw with the safety switches off and a sticker reading for general use. The admin's job — the entire admin's job, the thing he is paid to do — is to engage the safeties before letting anyone near the chainsaw, and to choose a different tool entirely when the workload calls for a scalpel.

Lazy admins blame Linus. Senior admins blame themselves, audit their fleet, and quietly migrate the workloads that should never have been on a general-purpose Debian box in the first place.

References

Tagged:
#linux #security #kernel #sysadmin #cve
← Back to posts