Kernel Recipes 2026 - Security in the LLM age

Greg Kroah-Hartman’s Kernel Recipes 2026 talk examines what LLM-based security tools mean for the Linux kernel and open source maintainers. Speaking from direct experience with the Mythos framework (he was publicly named as one of the people with access), he dissects Anthropic’s widely publicized “79 kernel bugs” report, shows how few of those bugs were real, and argues that the security community should neither panic nor celebrate: LLMs are fuzzy pattern matchers, not intelligent analysts. His core message, repeated throughout, is “do not panic” — sit down, fix the bugs, and grind through it the same way the community did with fuzzers and Y2K. The second half of the talk is practical advice for developers and maintainers on handling the flood of LLM-generated reports and patches, including how to spot them, how to push back, and why you should never upload non-public data to these tools.

Key Points

Detailed Summary

Opening: the CVE flood

Greg opens with his annual talk for the kernel community (developers and maintainers specifically, not the general public). A year ago he reported the kernel producing ~50 CVEs a week; it is now 33 per day. The tooling he, Lee Jones, and Sasha Levin built for the earlier scale has paid off — the kernel team’s infrastructure handles the load fine, while the wider CVE ecosystem and CNAs are the ones panicking and rebuilding. His refrain for the talk: do not panic, and ignore the doom marketing.

The Mythos story

In early February he got the phone call about Anthropic’s Mythos report claiming 79 kernel bugs, and got access to the raw data. His breakdown of the 79:

Of those 20: seven assumed a malicious handcrafted filesystem image (the quintessential newbie non-security bug), one assumed root could inject packets mid-stack, two were no-MMU bugs (including an io_uring no-MMU bug he fixed — and evidence that nobody actually runs no-MMU systems), six were SCTP bugs relevant only to enterprise telco networks, five more were minor IPv6 issues of minor issues (two duplicated), and one was a GPU driver issue requiring an already-malicious local user. The end result: about ten real fixes, roughly one hour of kernel development at the normal pace of ~10.5 patches per hour. Marketing inflated it to a global story.

He notes the Mythos framework itself is well built — it spun up a no-MMU RISC-V VM, wrote a test case, and exercised io_uring — but it is a framework around a dumb chatbot. He also mentions he was doxxed by Jim Zemlin as the only named person with Mythos access, and that he found and fixed more real bugs in an hour than Anthropic’s report did.

The real problem: deployment, not discovery

The genuine danger in 2026 is not that the tools find bugs — it’s that people don’t roll out fixes. The classic discover → disclose → patch → deploy cycle used to give ~63 days before exploitation appeared; it’s now around negative seven days. LLMs persist relentlessly and can chain many minor issues into real access, which makes fixing even minor stable-tree bugs important. But the deeper cause is years of unpatched deployed software — “the bill is finally coming due” — and Greg is now hearing banks say they will actually update their systems, fifteen years after being told to.

Grind through it: fuzzers, Y2K, and rsync

His prescription is historical: the community survived Y2K and the fuzzer storm of six or seven years ago by sitting down and doing the work. Fuzzers still hit the kernel daily; nobody panics anymore. When bugs are fixed, they stay fixed. The rsync project is the showcase: Tridge and others ground through everything the scanners found, rebuilt the testing infrastructure, and the latest rsync now comes back clean from every code scanner. CNCF core cloud projects scanned clean too. These tools can go deeper than fuzzers because they’re static analysis — the same idea as Coccinelle from decades ago — but the noise stops once the bugs are fixed.

On the companies behind the tools

Greg is blunt: these companies “sucked up our data” and admit they obliterated copyright (amusingly serving an FSF goal), while compensating no one — so developers shouldn’t pay for the tools either. He cites LG Research in Korea finding that only ~20% of the foundational training data is legally usable. His attitude: they spent billions building a fuzzy pattern matcher that finds bugs in open source — fine, let’s use it against them and make our software better.

Handling the flood of reports and patches

Practical guidance from his past year of research (six graduate students reviewed large volumes of bot output):

Leaking and confidentiality

Anything uploaded to these services leaks — to other users, to the vendor, to training. He cites the mathematicians’ experience with Claude and the weekly stream of people angry that “their” bug was reported publicly a day earlier after being scraped. The rule: run local models, and never upload anything non-public. Offers to pipe the security@kernel.org feed through someone’s cloud model are flatly refused.

What the kernel community is doing

For developers and maintainers

Q&A highlights