Some talks just write themselves, @KernelRecipes is going to be fun this year!

(not that it's not fun every year, but you get the idea...)

If you're interested in the design of agentic workflows, remember this formula:

R = 1 - (1 - P)(1 - C)

This article starts with a story from someone who tried Claude Code and found it amazing, but then switches to the same person a few months later seeing what a disaster it’s been. This quote is key:

The problem is that code produced by an AI agent looks reasonable, but can contain ‘hard-to-spot bugs’ that end up causing major problems

LLMs, by their nature, generate statistically plausible output. That is often a set that overlaps with correct output. But the things that are not correct look exactly the same as the ones they are.

Learning to review code is hard. You look for the bugs that you expect to be possible implementing it by using your theory of mind for the person writing the code and the kinds of things that they might overlook (not necessarily a specific person, but the kinds of things people miss) and also common bug classes.

And the big help is that the person writing the code is not thinking adversarially. They are not trying to sneak bugs in. Normally. Unless they’re a supply-chain attacker, and we’ve a depressing amount of evidence that code review doesn’t catch supply-chain attacks.

An LLM is not trying to do anything. It has no intent. But it is a machine that is trained on code that made it past code review. The kind of bugs that it will generate are ones that look like code that appeared in production. This is exactly what an attacker would do: try to write code that looks correct but is subtly wrong.

I’m only being slightly flippant when I say LLMs are a mechanism for bringing supply chain attacks in house.

In which I explain how I will treat LLM generated or assisted patches for the Linux kernel drivers/staging/ subsystem going forward:
https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh/T/#u

(hint, not allowed, except for security bugs that you can prove actually fix something by testing the issue on the actual hardware the driver controls.)

Meet the 2026 Kernel Recipes mascot.

Curious, optimistic, and very much in tune with the world around it.

This year, our little penguin is thinking beyond code. From sustainability to responsible tech, it reflects values that have always been close to the open source community.

With the devastating wildfires affecting France this summer, it also reminds us that technology doesn't exist in a vacuum. The challenges we face are shared—and so is the responsibility to build a better future.

Another one of those mornings....

More from our keynote @netdevconf https://www.netdevconf.info/0x1A/sessions/keynote/llms-and-the-kernel-security-process.html #netdevconf

You don't see people from the frontier models brag about how many vulnerabilities they FIXED, only how many they FOUND.

“Very few companies are so good at shipping software that they can afford the extra risk profile.” (of #AI)

From:

https://hermit-tech.com/blog/ai-mania-is-eviscerating-global-decisionmaking

Linus once more states that AI is just a tool:

https://lore.kernel.org/all/CAHk-%3Dwi4zC%2BZe8e%2Bp3tMv8TtG_80KzsZ1syL9anBtmEh5Z40vg@mail.gmail.com/

"" #Linux [the #kernel] is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it.

Or just walk away.

AI is a tool, just like other tools we use. And it's clearly a useful one.

It may not have been that "clearly" even just a year ago, but it's no longer in question today.

There are other questions around AI (like what the economy of it will actually look like in the end), but "is it useful" is no longer one of those questions. […]""

#LinuxKernel

#LKML #QOTD from Tytso in reply to a #ext2 backporting request to various older #Linux longterm #kernel series:

""[…] And this is why the patches have not been backported. It requires work, and an AI generated request doesn't change the reality that *someone* has to do that work,

I invite you to figure out a way to figure out an AI mediated tool that can attempt the backport, and then run the moral equivalent of "gce-xfstests -c ext4.all -g auto" to verify that the backport doesn't result in any regressions. (Some previous attempts to backport to older LTS kernels have resulted in the kernels crashing as a result.)

Otherwise, I recommend that most users consider switching to a newer LTS kernel, or if they can't to pay $$$ to an enterprise Linux distribution that pays engineers to do that hard work.""

https://lore.kernel.org/all/alDWUmORy7fTnorX@mit.edu/

Side note, regarding the "switching to a newer LTS kernel" aspect: running at least the latest longterm #LinuxKernel is what most users should do anyway, as explained by this post from @gregkh:

http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/

CVE issue stats for the first 6 months of the year, by vendor, sorted by quantity:

   2308 "vendor": "Linux",
   1752 "vendor": "Google",
   1308 "vendor": "n/a",
    843 "vendor": "Microsoft",
    495 "vendor": "OpenClaw",
    445 "vendor": "Oracle Corporation",
    395 "vendor": "Adobe",
    340 "vendor": "Red Hat",
    310 "vendor": "Apache Software Foundation",
    284 "vendor": "Apple",

I gotta change my talk where I say “we are #2” as that’s not the case by far anymore. Hopefully the other vendors get their act together and start properly reporting all CVEs to the system, not just the ones that they feel like submitting…

And the numbers for OpenClaw is quite impressive, nice to see someone take responsibility there :)

Podcast I did a few weeks ago with OpenSSF is finally up:
https://openssf.org/podcast/2026/06/30/whats-in-the-soss-podcast-64-s3e16-the-heartbeat-of-the-kernel-why-upstream-is-the-ultimate-security-strategy-with-greg-kroah-hartman/

"You're a commercial user of libcurl who use it for free and you ask a volunteer to fix your problem on his spare time?"

Sometimes I need to say it.

'Untrusted data in Linux — How Rust is going to save us' by Greg Kroah-Hartman at RustWeek 2026!
https://www.youtube.com/watch?v=Nzmj7K0FNRY&list=PL8Q1w7Ff68DBpmF38rcIAf8Z9Gj2TnlgM&index=11

#rustlang #RustWeek

As every year, Kernel Recipes is running its charity auctions!

This year, we wanted to shine again a spotlight on the work of the @conservancy. @bkuhn will be speaking on the topic on September 22nd, right before the auctions kick off.

Registration for the conference is now open: https://www.billetweb.fr/kernel-recipes-2026

The #curl project will not accept or otherwise handle any vulnerability reports during the month of July 2026. We call it the curl summer of bliss.

https://daniel.haxx.se/blog/2026/06/15/curl-summer-of-bliss/

We are honored to announce the @netdevconf 0x1A keynote speaker @gregkh !

@gregkh will discuss the ongoing LLM challenges and the kernel security process.
Come hear and learn and interact to provide feedback to @gregkh

https://netdevconf.info/0x1A/sessions/keynote/llms-and-the-kernel-security-process.html #netdevconf

Assisted-by: GNU sed 4.9 <sed@gnu.org>

New live episode of Rust in Production and it's a special one! 🥁

Recorded on stage at Rust Week in Utrecht with two people shaping the future of the Linux kernel:

🐧 Greg Kroah-Hartman (@gregkh ), Linux Foundation Fellow
⚙️ Alice Ryhl, core maintainer of Tokio, Rust for Linux at Google

▶️ https://corrode.dev/podcast/s06e04-rust4linux/

Huge thanks to the Rust Week crew for hosting this one. You're awesome! 🦀

#Rust #Linux #RustForLinux