A thousand fewer paths to root

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.

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...

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.

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.

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.

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

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.

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.

Yes, and that's well known.

> Is it an underlying flaw in the security model or language implementation?

Yes, both, and that's well known.

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

No, some software out there is smaller and have more automatically enforced correctness.

We should expect every large software not created over a simple correctness enforcing stack to have the same number of issues. Linux is just a worst case here, so is your internet browser.

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

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.

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.

There are ways where humans are still much better than AI at coding and especially at architecting and coming up with solutions.

But finding vulns is a clear AI strength since it can connect keep so much more related code in context than humans can.

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

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)

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.

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.

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,

Simians hand coding.

We did our best.

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.

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.

We developed AIs that can find them.

We were all drunk and manic frankly

Also, let's maybe not call the result impressive until we see what's under the hood.

Want the build the stats? Data mine the patches, and infer it yourself, publish it if you want to. That's how some people find bugs that aren't disclosed as explicit security fixes (and not every security issue needs a disclosure and fancy name, especially if it is introduced,found and fixed in a dev cycle before the code is part of a release)

(As someone who used to handle nonpublic Linux kernel security reports and is still very interested in this stuff, I’d love to review a small sample of these reports to get a feel for what kinds of issues are being unearthed.)

Also, please don’t stop at LPEs and information disclosures. If you find cases where Linux can be convinced to misbehave or where the implemented semantics don’t make sense, these are good, too. I’ve found plenty of interesting kernel bugs, including some juicy LPEs, and almost none were memory safety errors :)

I understand this work was based on a dated snapshot. Will there be any continuous effort, scanning new PRs as they land, to prevent new weaknesses from being added?

E.g., 948 results is a high number to review in a timely manner unless your team is very large or spending several months combing through the results

EDIT: nvm i shouldve kept reading, answered

> At this scale, manually investigating every report is impractical for our research team. We therefore focused on validating findings that a) were reachable by a low-privileged user, b) required no special capabilities, and c) produced measurable evidence of memory corruption.

Presumably, the barrier to sophisticated supply chain attacks is falling rapidly due to LLM agents. Such attacks could even be utilized by a rogue AI. OpenAI could easily develop internal expertise in detecting such attacks via the following method:

* Train an LLM agent to create binaries with subtle backdoors/bugdoors

* Train another agent which ingests data in the form of clean binaries and poisoned binaries, and learns to tell the difference

* Train in a loop, where the first agent "wins" if it fools the second agent with an implant judged useful by a 3rd un-incentivized agent; the second agent "wins" if it's able to detect increasingly obfuscated backdoors/bugdoors

Over time you could train a small model for high performance on this task, which continuously scans open-source package repositories, firmware, OS release images, etc. flagging issues, and certifying hashes as free of apparent malicious code. To save on hardware resources during continuous monitoring, it could also learn to scan binary diffs. A certification API could then be exposed for use by maintainers of apt-get and other package tools.

This could be excellent as a goodwill project to help prevent security apocalypse and harden against rogue AI.

Originally had this idea in this subthread: https://news.ycombinator.com/item?id=50379912

The article says "The target virtual machines ran a stock desktop operating system". Are the vulns in the kernel specifically or does this include software running as root?

A system that admits THOUSANDS of such vulnerabilities is certainly flawed in several fundamental aspects

And, well, since you didn't _specifically_ ask for questions about the blog post:

Why are you not quitting your job in protest and screaming at the top of your lungs about it, seeing so closely what these models are capable of that your company is creating? There exists now something that is able to find 948 kernel LPE vulnerabilities. How, exactly, will humans be able to control and contain, say, next year's models for a nonzero amount of time?

Would be nice if the page could be readable without.

...and then proceeds to never answer a single question. Classic.

Greg Kroah-Hartman showed [1] how thousands of AI reported bugs can shrink to a handful after maintainer review. How many of your 948 LPEs have been independently confirmed upstream, and do you expect similar consolidation?

Are there plans to make these cyber capabilities more accessible to independent security researchers? Current restrictions risk putting legitimate defenders at a disadvantage.

[1] https://www.youtube.com/watch?v=NnV_cWeoo5Q

I guess the answer is that in most applications you are able to keep most users off the box altogether.

If only the kernel maintainers considered the thought which first came to your uninformed mind, they would have saved some effort...

There are plenty of design decisions that could fundamentally change things. But they're not being taken. What you're seeing is the revealed preference of this system: Security is important, but not enough to make people incur the cost of adopting major changes in pursuing it.

But if I wanted to learn software design and architecture, I'd probably not even know where to start.

Hopefully this type of work to automatically discover & patch vulnerability leads to much more reliable software, and the remove the need for cyber security.

[1] https://www.cyberdefensemagazine.com/zero-day-market-the-gov...

To explain more seriously, almost all visible cyberattacks are carried out by profit-motivated criminals. This has a very clear cost-benefit analysis; your revenue is hacking organizations and extorting them for available money, and your costs are developing and deploying attacks. The ROI is outrageously good easily being on the order of 10x to 100x. If it is so easy and so profitable why do not they just hack all of the millions of organizations on the planet with millions of dollars of available cash for trillions of dollars of revenue? Sure, all they have to do is create a trillion dollar revenue commercial organization bootstrapping themselves with no outside investors, loans, or access to financial resources or the financial system.

I mean, it took Mark Zuckerberg 20 years and a metric ton of VC investment and public investment to make 200 billion dollars in revenue. So what kind of loser can not make a commercial organization 5x larger with a trillion dollars in revenue in less time with no outside investors? Are they even trying? Just make more revenue than any other commercial organization in the entire world and extract that money in a freely usable form, how hard can that be?

They are not there yet, but they are trying. If you look at cybercrime reports you see something like 3x-10x growth year over year. Ransomware reports from a few years ago were showing a 3x year over year growth in number of attacks and simultaneously a 3x year over year growth in ransom amount with the averages being on the order of 100,000 dollars. Chump change for any serious organization, but give that a few years of 3x and that starts to look like real money. However, as it becomes real money it becomes harder and harder to launder it into a usable form. Sure, you could hit someone for 30 million dollars, but how are you going to get that into your bank account? Cryptocurrency helps some, but even there the big money tries to steer away from large overt crime. Maybe you could launder a few tens of billions a year that way, but that is still a far cry from the trillions for everything everywhere.

And of course even assuming you can scale your organization 10x year over year it still takes a decade of sustained growth, scaling your hiring and organization across 9 orders of magnitude, to get to billions per year. A literal decade even if you were growing at a outrageous pace for a outrageous amount of time just to reach a fraction of the total addressable market. A decade of that and you are still nowhere near blowing up all the power plants. Give it time, we need a lot of bears to get there.

lol

As models get better and porting costs get lower, maybe it's better to bite the bullet and RRiR instead of having a minor bugpocalypse every 3 months, as each subsequent generation of frontier models finds sev-high CVEs?

"you're going to need to do multiple rounds of scanning so we recommend budgeting $3.6 million a year for buying tokens from us not just $1.2 million.

Dont worry just give us a few million dollars and you'll never get hacked, you can cut your security staff in half to pay for it! We definately wont cause more bugs!"

Yeah yeah we're all going to be left behind if we do not jump off the same cliff everyone else is jumping off.

It is wrong to try to take your own lessons from this and do the thing but in a less harmful way. Just do exactly what the labs want you to do.

Jesus man

The difference here reminds me of the distinction between the regular Paxos algorithm and the Byzantine Paxos algorithm.

You don't need SOTA models to pend test your systems.

With enough effort put into proper harnesses, you can use good open-weights models and achieve a lot.

You can also use coding agents to clear out technical debt, or improve the security architecture.

Don't let yourself get paralyzed by lack of access to the latest-and-greatest models.

You can the same $20/mo Claude code plan you've been using to build your system to red team attack the system you've been building with it and probe it for holes, and it'll do a decent job of making sure there aren't any glaring issues.

It is however reasonable to assume that a lot of bugs that are being found by the community these days were found thanks to those people using AI to aid them.

See for example what a PostgreSQL developer is saying:

> All software contains bugs, and PostgreSQL’s code base is large, complex, and old. Our git history – converted from CVS – now reaches back more than 30 years, and the first code was written a decade before that. There’s a huge amount of code, and that code contains a huge number of bugs. That’s always been true, and it hasn’t stopped PostgreSQL from being popular or successful. What’s different now is that it’s become vastly easier to find those bugs. […]

> […]

> […] a huge number of people on the Internet are now reporting bugs in PostgreSQL that they found using LLMs, and the PostgreSQL committers have been very, very busy fixing them […]

http://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-it...

https://news.ycombinator.com/item?id=50312408

https://www.anthropic.com/glasswing