@giggls Agreed, and it's on that site as well.

This site wins the internet for the week: https://www.getrandomnumber.org/

I'm not sure claiming "everything is on fire" is the correct takeaway here

There is a pile of flammable materials we've been ignoring for decades. It catches on fire sometimes. It caught on fire a lot this week

And the people who put out the fires, for free, put the fire out again

The current plan is to just keep throwing more oily rags on the pile. We could try to help the volunteers, but that costs more than adding oily rags to the pile

New usbutils release: https://lore.kernel.org/all/atmyfUVyCnr5WnJh@kroah.com/

⏳ 2 weeks left to nominate for the European Open Source Awards 2027!

The European Open Source Awards exist to make the quiet work visible, and to celebrate the individuals and communities advancing innovation, collaboration and digital sovereignty in Europe.

👉 Nominate by 1 November: https://awards.europeanopensource.academy/nomination-process

#EOSAwards #OpenSource #EuropeanOpenSourceAcademy

@philipmolloy nothing special, using Arch Linux and ramalama to serve stuff up.

Gave a 2+ hour lecture at vu.nl today about Linux kernel development and security things that was a lot of fun, the students had great questions about a huge range of relevant topics.

Afterward a student gave me a vanilla cake baked by their grandmother.

Best speaker gift ever.

Claude.ai rightly points out that when reviewing code, we should focus on the code and not on its author.

We all hate this

@gregkh dropping necessary bombs about LLMs in Linux security and development.

https://www.youtube.com/watch?v=NnV_cWeoo5Q

The purported 79 vulnerabilities were mostly bogus (not a bug, fabricated data) or had already been patched; the few real (all very minor) bugs took him an hour to fix. He says "do not panic", and emphasizes that time to apply patches is the main vulnerability these days (not an LLM problem).

"These are pattern-matching tools", "they do not have intent". (Vindicating to @emilymbender and @timnitGebru re "stochastic parrots"; it was accurate at the time and accurate today, protestations from boorish AI boosters notwithstanding.)

New code is 50% wrong, generated code is littered with new vulnerabilities; need to reject a lot but believes review processes are adequate to prevent a shipping a flood of LLM-generated vulnerabilities.

High false-positive rates make the models incredibly irritating. Cf. Coverity's post-mortem with a deterministic tool that had low false-positive rates.

Push back hard [on corporate marketing to developers]

With regard to higher CVE rates:

We'll grind it down like we did with the fuzzers.

If you want to look for bugs with an LLM (which amounts to fuzzy pattern-matching), use a local model and never upload to platforms.

I have banned LLMs from driver staging, unless you have the hardware and can prove you have tested the patch. That's not what staging is for. Staging is to learn how to do development and get involved with our community. [...] Kernel development is all about trust. If I take patches from you and I don't know who you are, now I am responsible for that patch. [...] You need to build up trust.

It's put a lot of additional burden on us, as maintainers.

@heine @muvlon @KernelRecipes @philipmolloy you are right, `make sbom` is newer than 6.18, it showed up in the 7.2 release.

@jbm @KernelRecipes @bagder On nevermind, I can't do math...

@jbm @bagder @KernelRecipes We got CVE-2026-100001 as well :)

Here's a bit more up to date version of the "how many CVEs have we fixed" stats than what I showed earlier this week at @KernelRecipes as I was able to catch up on some reviews on my way home on the train.

Also cve.org just crossed the 100000 numbering barrier just now, first time that ever has happened, hopefully no scripts broke. And yes, the kernel.org CNA has CVE-2026-100000 reserved, need to find a "good" bug for that one, suggestions welcome!
https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/100xxx

@heine @philipmolloy @KernelRecipes @muvlon Has everyone ignored the 'make sbom' kernel build option that will tell you EXACTLY which files your kernel build uses? You can then cross-reference that with the files in the CVE entry (both of which are in json formats, so script away!)

There's also many other older tools out there to get a simple "here are the files I am using for this kernel build" list, here's my very old version that has been used by Android in the past:
https://github.com/gregkh/gregkh-linux/blob/master/scripts/count_lines

#Linux 7.3, since a few hours ago, will definitely be the #kernel with the most commits, as right now it already has 18.672 (17.410 if you ignore merges).

The previous record holder was 6.7, which had 18.404 (17.284) -- and was bigger than other releases at that time because it contained nearly 3,000 commits of bcachefs history.

For more stats on #LinuxKernel releases, see https://docs.google.com/spreadsheets/d/1_yH7lFmZxAoSWrtsd8tGu3befG4zIcMnytB1ml4pQQM/edit?usp=sharing

@philipmolloy @KernelRecipes @muvlon Awesome, that's the way to do it, nice work!

@gregkh @KernelRecipes @muvlon we've partially addressed this confusion at ADI by generating CVE lists specific to our defconfigs:

https://analogdevicesinc.github.io/linux-security-vulns/#known-vulnerabilities

It's like everyone who came on board to AI because "they can write code now!" thinks the primary argument the rest of us have is "no it can't"

So I'll be the one to say it: yes AI can write code. I believe you. They can write code. It compiles. It even passes the tests that the AI also wrote.

Unfortunately the code they write is shit. It's automated technical debt with built in landmines. You think people coding in C causes issues? Wait'll you see what LLM code produced on massive scale does

@danluu more importantly, other companies were even worse, as @gregkh mentioned in his presentation. And they were shielding their internal on-payroll developers from the false positive firehose, always qualifying the bugs much better than what they sent to OSS devs.

@muvlon @KernelRecipes It has that many listed CVEs because our codebase is huge, but you only use a small fraction, so what is relevant for you is much smaller.
Also bugs at our level are CVEs, while userspace programs don't have those same issues.

This is nothing new, other operating systems have the same issues and lists of CVEs. It's just that the corporate OSes don't actually publish all of their vulnerabilities because nothing requires them to, so they don't. Go blame them and the cve.org people, not us!