Because the large corporations that fund Linux development and use Linux value speed over security.

Speed requires a lot of code in the kernel, where that code can run fast.

There are kernels that do not have a thousand privilege escalation exploits. These kernels are smaller and much easier to check for bugs. But those kernels are significantly slower.

For many use cases, slower is not a problem. But for the large corporations who fund a lot of Linux development and use Linux in large data centers, every 1% slower can literally be millions of dollars worth of additional servers that are required.

OpenBSD shows that you can have a Unix security model without a thousand privilege escalation exploits. But OpenBSD is like 10% slower. So corporations won't use it because it would cost millions of dollars more per year and some of their software requires access that OpenBSD does not grant precisely because that access leads to security exploits (i.e. io_uring, eBPF etc. etc.)

You could also use like seL4, but that's slow too

So that's why. It's a business tradeoff between cost of servers vs cost of getting hacked, and cost of servers wins.

Many people seem to be making this about their pet issue, but "these systems are complex" and "the frontier labs have developed models that are superhuman at hacking" seems like a totally sufficient explanation.

I've been working with a LoRa chip called the LR2021. I plugged a dev board into my computer and told Claude to reverse engineer it. He dissected it with a speed and level of efficiency I couldn't believe. Within a few hours, Claude was writing custom patches for a completely opaque patch RAM area meant only for the manufacture. I wrote about it here: https://beala.substack.com/p/your-node-doesnt-need-a-microco...

> Should we assume that all software is more compromised than the kernel?

Absolutely, the front door has always been unlocked. We were previously protected by the economics of exploit detection favoring the developers, but now we have entered a new world.

The issues arise almost everywhere we look. It's frustrating because the user experience in edge systems has barely changed in the last fifteen years. We could have rode the advances in semiconductor manufacturing to embed more layers of protection such as CHERI while slightly slowing down the rate of performance improvements. Instead we have only marginally upgraded security and largely added features which the users scarcely notice.

I am hopeful about the long term prospects of formal verification, but having humans reviewing the proof statements and confirming they match our desired properties will take many years. Meanwhile, AI assisted hacking is an urgent issue. So we will have to delegate implementation, proof specification, and proof development to the AIs in the short term. Maybe that goes well, but who knows. Interesting times.

> Is the kernel simply too complex to reason about?

Yes it is. Not just the kernel, almost any application with more than a few thousand lines of code too. AI has humbled me so much I don’t believe humans have ever been able to fully understand and modify systems like that, we just did the best we could, wrote some tests and hoped for the best. If you use a language like C, as the kernel mostly does, then you’re really asking for vulnerabilities everywhere. Even Haskell code bases are buggy, languages just aren’t a panacea when it comes to writing reliable applications, but they at least make whole categories of bugs impossible by design, ignoring that is a crazy thing to do in 2026 with AI being able to scan your full code base in hours, it’s guaranteed to find exploits at will.

For all of my time being aware of this industry, it has generally been understood that privilege escalation bugs are common. This has always been a thing. A lot of people say, commonly and for many years, that if your security depends on there not being privilege escalation bugs, you don't have security.

That's the drawback of monolithic Linux and tendency to put everything in kernel.

It is absolutely possible to have very minimal kernel with drivers and many other subsystems running with lowered privileges.

That would greatly reduce privilege escalation possibilities. Right now single vulnerability in any kernel subsystem gives you highest access to the system.

Imagine that some USB device driver runs as "nobody:nobody" process having access only to selected syscalls related to its functions. Even if it has vulnerability, you won't go anywhere from there.

Modularity and very granular access controls are the "secret" to secure system.

And the most privileged part of the kernel could be so small that it could be verified with advanced methods, basically proving its correctness.

> How did we get to the point where there are a thousand privilege escalation exploits in the kernel? [...] Is it an underlying flaw in the security model or language implementation?

Did you ever actually think that any OS built with an insecure language and insecure tool chain suddenly, casually and accidentally, spontaneously became Secure one day like some kind of Security Singularity?

Threat actors have been mining software flaws and exploiting software for decades. There were careers and businesses built on this mess long before there was a category of software called AI. And LLM products have security problems like any other software.

There's probably relatively few exploits in the kernel itself. It's all in the drivers, that run at kernel-level for performance reasons and are developped by manufacturers.

The dirty secret is multi-user died in the 90s and privilege escalation has basically been considered table-stakes since then.

It's just too complex for its level of assurance and its blast radius.

To achieve tolerable security you can either have very little code and thoroughly review it all (the seL4 approach), you can write it in a way the computer can prevent most of your bugs (e.g. write in Rust), or you can run it in some kind of blastproof container. Linux has none of the above.

All software is Swiss cheese to smart enough AI, and unless you can provably create secure software - you never really can. Breaking it just requires more intelligence than the thing securing it.

It's a good reason why we may need to borderline shutdown the internet in the future because to a super intelligent AI, there are no barriers. Everything is essentially open. It creates its own zero day exploits as it goes.

>Is the kernel simply too complex to reason about? Is it an underlying flaw in the security model or language implementation?

There is nothing magical about kernel. Look at the code anywhere and it has bugs, lots of them.

Security bugs are just bugs. More often than not they are silently there and don't prevent you from using the software and you can't react and fix them because of that.

Give it time and they accumulate

Yes, you should assume that all software you use is full of holes, and after we patch all the holes that could conceptually have been discovered by a motivated human, there will still be holes that can only be found by considering larger windows of context than any human has or could. Even when something is formally verified, that doesn't extend to its software environment or the hardware it's running on, and those can introduce exploitable vulnerabilities as well. You can only ever be very confident that we've found all the holes at a given analysis capability level -- if something a hundred times as capable looks, it will likely find many more. That's how it will be.

Decades of accruing bugs.

The kernel probably is too complex to reason about. C is notoriously hard to write correctly and will compile with a very large amount of errors.

Probably not, the kernel is written in an unsafe language, it's rather long handles an incredibly large space of concerns, including the handling of permissions.

Linux is open source - that gives the security AI tools an easier in - which is a bad thing, on the other hand it means that lots more vulns are being fixed.

Windows on the other hand is not, the same tools are going to find vulns in the binaries, but wont have an easy way to provide patches

Linux is going to get safer faster

Cause it's a big ball of C with no formal verification!

I'm not an expert on Rice's theorem but I believe it implies that 100% secure software is not possible.

And finding exploits manually is so incredibly time consuming, and the number of people who are good at it are so few. I don't think the result of thousands of existing exploits is suprising.

I think we will start to see more and more remote hardware exploits as AI improves. Especially with IoT devices. The limiting factor being AI's ability to interact with the real world,

I guess it is because most of it runs in ring 0, there would even be a ring 1 and a ring 2 but nobody uses them (even other OSes)

I think there's a bit of a 'normalization of deviance' here.

First, the kernel has a bunch of LPE (local privilege escalation) vulns. People running Linux hear about this and think "hmm, I think it's probably not a good idea to rely on user privilege separation for my security goals" and route around the problem by using other mechanisms such as VMs. As a consequence, the pressure on kernel developers to avoid having LPEs drops, because "everyone knows" that you can't really rely on user separation anyway. When LPEs get reported, they do get fixed, but with a sort of shoulder shrug. Nobody is paged at night because shared hosting is dead and everyone runs VMs.

The same thing sort of happened with containers. "Everyone knows" not to trust them so Linux namespace escapes are kind of whatever. I don't think either interface (classic UNIX users or containers) is fundamentally impossible or even that hard to secure. Virtual machines, at least the QEMU/KVM type, also expose a ton of attack surface (like a virtual floppy drive? not kidding, that has been a source of CVEs) to their guests, and they do have VM escape vulns every once in a while. It's just that we have collectively decided that their security properties are more load-bearing than those of users and containers, and we only have finite resources to invest so maybe it makes sense to at least have one boundary with okayish security?

That being said,

> Is the kernel simply too complex to reason about? Is it an underlying flaw in the security model or language implementation?

I'd say yes to both. The kernel is too complex to reason about interesting properties such as sound user separation. It's also written in a language where memory management requires very complicated non-local reasoning and even the smallest mistake often has grave consequences.

Human brain mostly take the shortest available path for a solution to reduce the cognitive load. When a system complexity increases probability of cutting the corners will get increased. This is a known pattern. Models just do the polar opposite. They try to cover almost every hypothetical edge cases. They never get tired or bored, nor do they suffer from glucose limits, mental fatigue, or shifting attention spans, which is one cause of over engineering, but valuable in vulnerability tracing.

Have you written a kernel? Even toy kernels are hard to make without vulnerabilities.

> How did we get to the point where there are a thousand privilege escalation exploits in the kernel?

it's been rule of thumb basically forever that there is 1 bug per ~10KLOC for any project

linux kernel is millions of lines, so thousands of bugs being hidden there is about on point

(tho obviously far smaller serious escalation ones, obviously, but you're exaggerating as well)

How can it be surprising that a software made from 40+ million lines of memory-unsafe code has hundreds of critical bugs?

I recall reading that every IBM mainframe OS release had 1000 bugs in it. (This was in the 1970s/80s.) Sorry I can't supply a source, after 4-5 decades. It was probably an article in Datamation magazine.

Now, I don't know how many of those bugs were privilege escalations, or could be leveraged to be. I'm not sure that people tried to exploit in the same way back then (or, if they did, if they said anything publicly about the results). Still, even if the majority of those bugs were not exploitable, OSes were much smaller then.

So that's my conclusion of how we got here: We've always been here.

The Linux kernel is simply not good quality code.

AI helps find vulnerabilities, but the way things are written were already fertile ground.

Software really is that complicated.

It has virtually 0% unit testing coverage.

The overwhelming majority of CS was invented in the 1970s before the concept of the internet or even computer connectivity was a thing.

That's how computer science and software engineering have always been: https://xkcd.com/2030/

amazing things happen when you decide that device drivers should be a part of your kernel codebase

> How did we get to the point where there are a thousand privilege escalation exploits in the kernel?

We developed AIs that can find them.

The kernel is not too complex to reason about. There are many tools and systems that can reason about the kernel, including these LLMs. But the kernel is developed and maintained by people who eschew such tools, because it appears more manly to program by the seats of their pants, and they have been vocally against all industry best practices for almost 40 years now.

What I am really hoping is not that LLMs refine Linux until it is almost acceptable, but that LLMs enable teams to ship useful new operating systems that aren't beholden to decades of macho bullshit.

> How did we get to the point where there are a thousand privilege escalation exploits in the kernel?

Local privilege exploits have been accepted as being there in Linux ~forever. The past 10-20 years with containers, people have tried to kind of ignore it or pretend it doesn't exist. Nobody with any serious security concerns would ever put untrusted users on the same box, containers or no. Virtual machines are where there is a bit more effort to take this seriously.

You could quibble about complexity and architecture and language but I think at the end of the day it's primarily about incentives. There is not much incentive to make this secure.

I don't know if you would assume all software is more compromised, but you should assume that all software development follows incentives similarly.

People (us, me) and organisations supported and encouraged the use of a huge codebase in an unsafe language, wanting speed and features over security and test coverage

We were all drunk and manic frankly

[dead]

The kernel has the problem that basically every bug in it is also a security vulnerability. All software has bugs. Had Linux been written in Rust, and I strongly recommend a rewrite, it would still have bugs, and thus would still have vulnerabilities. But they'd be way less.