Good points. Unfortunately, they don't have the people nor the incentive to actually look into that.

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

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

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.

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

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.

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

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.

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

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.

Do you have a list of the publicly discussed or fixed ones?

(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 :)

It's a bittersweet result, like finding asbestos in your house. I'd rather know than not, but I would much prefer not having it in the first place.

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?

As models get more advanced and generate an increasing throughput of increasingly higher quality results, how are you determining when to trust its results and when human review is needed on what?

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.

Unfortunately no remote openings and a very limited set of offices. You’re missing out on a lot of talent.

Thanks. I'm not a programmer so I can't understand what is happening in the kernel by looking at the changelog, so I'll ask: Are the problems remediated structurally so that nothing like it can occur in the future, rather than just patching it up? Are there "lessons learned" that are being applied and documented here (like, "this problem looks like it's shape transports to other subsystems as well, let's fix them all in a disciplined way")?

I'd like to see a break down by age of code and part of kernel (drivers, networking, core ,etc ..)

My 2 cents: it would be beneficial to involve companies like RH and the teams behind many distros to work through those, it's not just about validating and patching but also about delivering them to the systems involved, a lot of people need to be involved, hence collaboration is required

The high number is really impression to the point of making me skeptic. Are these distinct vulnerabilities or are a lot of the related in the way vulns often are?

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?

Thanks for trying to help on the defensive side!

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?

I'm going to assume that there was "old" code that caused LPE vulnerabilities, but, The Linux Foundation have their own project Sashiko (https://sashiko.dev/), which analyzes each commit to the Linux Kernel for bugs and vulnerabilities using Googles models, my question is then, how many of the vulnerabilities you found were also caught by Sashiko?

> Enable JavaScript and cookies to continue

Would be nice if the page could be readable without.

I wish these blog posts included statistics on the categories of deficiencies that cause these vulnerabilities, and proposed measures to avoid them

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

> This is my team’s work. I’m happy to try to answer questions or take questions back to the team.

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

Yes, and we didn't need AI to figure this out. Linux has been averaging ~500 security-relevant bugs per release since at least early 2024, before LLMs got any good at security research: https://social.kernel.org/notice/B9nU6wnmFvh5atXSG8. Now AI has pushed it to ~2000 per release, which is considerably higher, but at this point, does it make a difference?

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.

This is what the Rust advocates have been trying to say for a decade now. But C enthusiasts would always chime in that those bugs were just caused by careless devs and a real C programmer is fine.

Sort of, but one has to be pragmatic.

The only thing I know is that if I wanted to learn how to program, I have thousands of tutorials on the Internet and Youtube teaching everything from if/else to data structures and big O.

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

Traditional finance can freeze and reverse funds though. North Korea can hack a bank but they can’t get that money out of the country.

'Could allow a local user to gain root'

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

We humans are vulnerable to anthrax or sarin as well, but countries exhibit restraint in using such agents, because retaliation would be gruesome. Having someone going full rogue with cyberattacks could even unite the US and China temporarily in order to whack them.

> When the autonomous scan and manual analysis finished after 10 days, 61 LPEs had already been patched upstream, 43 had staging patches, and 299 were being reported and discussed publicly.

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

If that was true, why are the Linux maintainers hard at work discussing and patching the issues?

> The flag is 'Y' which was unused, and can remembered as the user is "yeeting" the device being operated on here (thrown with force without regard for the thing being thrown).

lol

Systems still take some effort to actually exploit. For example, the vast majority of bugs they found here are local privilege escalations, and most security people have long learned that user separation in the kernel is not a particularly strong security boundary. Network-exploitable vulnerabilities are a lot rarer, and it's noteworthy that there have been a few big ones discovered recently, but it's a much smaller number overall.

In general computer systems have been known unreliable since the 1980s, especially when networked. The entire cyber security industry operates not by preventing intrusions in the first place, but by rapidly mitigating them when they inevitably happen.

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

It is effort & probability game, and very often lack of information is the only advantage - security by obscurity. Even completly unplugged system probability of security breach is higher than zero, as somebody with enough determination can breach the physical place security protections and just sit at the machine and turn it on.

The governments buy them up [1]. Nukes wouldn't be required for WW3.

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

Just in the last month multiple governments had to shut down important online services due to a PHP vulnerability, and seven EU countries have had disruption to their food supply after millions of dollars' worth of it was cooked in hacked fridges. We aren't at existential yet, but we seem to be getting there.

Not sure about this case but seems many of the vulns reported require physical access. At that point the vuln is irrelevant anyhow, your target is cooked a thousand different ways.

Because critical systems are mostly not accessible from the open internet

Cybersecurity operates under the "not enough bears" theory of security. There are a million people in a valley and a male and female bear. You do not need to outrun the bears, you just need to outrun the two slowest people. Next year there are more bears, but you still only need to outrun a few people. Then, one day, there are a million bears and they eat you all. But that day has not happened yet.

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.

> The community is already doing a great job at finding and patching the actual vulns without the attention-desperate big labs.

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

Have there been significant AI-assisted exploits found against software which is not written in memory-unsafe languages?

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?

Security has been treated by corporations as a cost factor only and therefore ignored for years and now it starts to hurt not having taken care of in the first place.

This just translates to,

"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!"

> If your company is against submitting your code to the frontier model companies for the many good reasons to avoid doing it, your software will eventually become a target if it isn't already.

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

> We are all just sitting ducks, until we have access to these models and enough tokens to pen test our systems.

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.

> We are all just sitting ducks

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.

Why wouldn’t your network be air-gapped?

This, but for anything Capital-gated. Imagine if all universities could get access to radiotelescope time, atom smasher time, quantum compute research lab access... frontier models on massive datacenters represents a huge new category of captured commons.

Everything is broken, it's just a matter of how bad. Just like it is impossible to write software that is free of bugs, it is impossible to write software that is free of vulnerabilities. Such is the nature of the field. The good news is we have well established tools in security to mitigate the impact of any one vulnerability.

LPEs are frequent enough that people no longer use low-privilege user accounts to sandbox potentially malicious software. They are only used to control access for well-behaved users without any intent to subvert the system, not attackers.

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

This has been true for DECADES.

Regular LPEs are not novel. The frequency has just increased a lot.

I love Talos. I've used it for years for a two-node k8s cluster. It just works.

I’d think they’d go a long way. You have to remember many jailbreaks in major hardened systems over the decades have come from gifted eastern european teenagers. Imagine giving this talent actual resources and a mandate to do this full time.

Anthropic ran Mythos against OpenBSD and only had 1 reported vulnerability.

https://www.anthropic.com/glasswing

There are a lot of LPE's in Windows too. Remember that it started out as a single user operating system, it took a long time to get software on board to not always running as admin.

Linux has effectively same options and more via LSM. I'm not sure why ACL is mentioned here since it exists on Linux too. What advantage do you mean specifically?

Oh no, they will not be secured against their own users :(