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.

@CounterPillow As I said, it is very obvious when a newbie is using a LLM, so this is a warning that someone should not attempt to do that at all.

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

@brauner @jann I appreciate the comment, but as I will only see the changelog that shows up in Linus's tree, that's going to be a mess. Perhaps just set the Fixes: tag to not point to older trees and then send backports when needed?

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/

@goetz @dentangle hm, no, the series isn't there, sorry, they got lost somewhere, I guess I thought they already were applied... Will queue them up for the next round, sorry. Also, email always works...

@goetz @dentangle It's in the 6.6.140 release already, released on May 17, don't you see them there?

@goetz was mirror.kernel.org issues, as discussed elsewhere, all should be fixed up now.

@christopherkunz just filter on the issuing CNA. For wordpress I think it is 'wordfence' as they issue most/many of the wordpress plugin CVEs, or look at the urls in the records, as they show 'wordpress' somewhere as part of the path/domain.

@christopherkunz Nope, I was wrong, wordpress is properly splitting the cves out to call out the vendor of the plugin affected, and not use them as the vendor. Which I guess is the proper thing to do overall.

All of this is in easily searchable json for anyone to look at if you want to do your own queries, just download it from https://github.com/CVEProject/cvelistV5.git

@christopherkunz Yeah, looks like wordpress has given up in reporting anything in 2026, probably due to their "issues" at the moment...

For “products” (which makes the vendor issue where a CNA issues for multiple software products go away), the numbers are a bit different:

   2309 "product": "Linux",
   1584 "product": "Chrome",
    888 "product": "n/a",
    497 "product": "OpenClaw",
    284 "product": "Windows 10 Version 1607",
    255 "product": "Firefox",
    153 "product": "Android",
    141 "product": "AVideo",
    136 "product": "Red Hat Enterprise Linux 10",
    124 "product": "iOS and iPadOS",

Again, remember, vendors like Apple, Microsoft, and others only report the ones they determine to be “high” to CVE, while open source, as we can not dictate use of our code, have to report everything as we don’t know how it is used by others (i.e. severity is hard, if not impossible, to properly judge.)

Again, gotta give props to OpenClaw for properly documenting all of their issues, I wish more vendors would learn from them…

@samuel "CVEmaxxing", if you don't mind, I'm going to steal that for my next talk!

And the Google/Microsoft codebases are for _different_ products from those vendors, not just a single codebase, so you can't really compare them that way at all. Look at the product if you wish to compare for products. For products, our numbers are way way higher because most commercial vendors do not report all CVEs, only the "high" ones.

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