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

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.

@ljs Good, don't let the haters get you down, you're doing great work.

(2/4) "You are holding it wrong!" - Greg Kroah-Hartman

How do you actually get these cursed LLM tools to produce a valid bugfix from a bug report? Greg's talk is hands-on, not theoretical - what works, what doesn't, and why most people are doing it wrong. Some ongoing legal discussions are expected to wrap up by September, which may let him speak even more openly on the topic going forward, so this could just be the first chapter.

'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/