Nostr notes by Greg K-H

This site wins the internet for the week: ...

2026-10-27T15:33:31Z

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

Here's a bit more up to date version of the "how many ...

2026-09-25T13:26:38Z

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 nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqmhdv67685938zvy06wtvq477r497fk49wa9m8gjg7s2s3g5lzeqst0pmw0 (nprofile…pmw0) 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

My secret kernel review tools were spotted in the back of the ...

2026-09-23T14:55:18Z

My secret kernel review tools were spotted in the back of the nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqmhdv67685938zvy06wtvq477r497fk49wa9m8gjg7s2s3g5lzeqst0pmw0 (nprofile…pmw0) room

In which I explain how I will treat LLM generated or assisted ...

2026-08-03T13:31:13Z

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

Another one of those mornings.... ...

2026-07-30T10:43:40Z

Another one of those mornings....

CVE issue stats for the first 6 months of the year, by vendor, ...

2026-07-03T09:35:22Z

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

@nprofile…mcwl Been there, done that, gave up as I just want to ...

2026-04-23T12:34:44Z

In reply to nevent1q…qzr8
_________________________

nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqhg2hvzx6sxxrwkk5a90eskxm9qu00lw26faq8yvdukfv7295uz6sxwmcwl (nprofile…mcwl) Been there, done that, gave up as I just want to get real work (i.e. kernel stuff) done faster.

After totally messing up my gdm configuration by foolishly using ...

2026-04-23T12:12:17Z

After totally messing up my gdm configuration by foolishly using `gdm-settings` (I didn't want the machine to suspend at the login screen for obvious reasons that doesn't play well with logging into it from other boxes), causing it to not properly even show a login screen, I've reverted back to running plasma and realizing it's been a long time since I last ran KDE and how nice it's gotten since then.

So, until I figure out how to wipe all gdm settings from the system (hint, I tried the "reset" option on gdm-settings and to blow away all dconf files that i could find on the disk, but odds are I missed something), I guess I'm now a KDE user until I move to a new system...

Dear semi-lazyweb, Given a git diff of a C/Rust codebase, how to ...

2026-04-06T10:21:26Z

Dear semi-lazyweb,

Given a git diff of a C/Rust codebase, how to best determine which functions/defines have been modified between the two versions? Yes, the diff itself sometimes gives hints as to what has changed, but it's not always correct. Think about when it modifies the start of a function, but the diffstat "name" shows the previous function, a correct marking, but not what is needed.

Is the correct answer really going to be "compile the two versions and compare the AST" or something like that? No "diff library" somewhere that "knows" how to parse C (and Rust) that can do this in a faster way? Surely I'm missing something obvious here...

In a few minutes I get interviewed by Shuah Khan and might answer ...

2026-03-31T13:47:55Z

In a few minutes I get interviewed by Shuah Khan and might answer questions from the audience if we have time: https://www.linuxfoundation.org/webinars/lf-live-maintainer-series-my-life-as-a-linux-kernel-developer-and-maintainer-with-greg-kh-and-shuah-khan

It will be recorded for playback later as well. It's part of the great Mentorship video series that Shuah has been putting on for years, the back catalog is deep: https://events.linuxfoundation.org/lf-live-mentorship-series/

We've gotten five different "security reports" about ...

2026-03-30T06:49:43Z

We've gotten five different "security reports" about the decades old USBIP protocol https://docs.kernel.org/usb/usbip_protocol.html and how it is "insecure" in the past few days.

Yes, it's only to be run between "trusted" devices, and we will gladly take patches so see the ones recently posted to the linux-usb mailing list to mitigate these issues, but this is very strange as to why all of a sudden this is being reported all at the same time by random different semi-anonymous accounts.

Is there some big usb-over-ip installation somewhere that people suddenly started caring about out there, or did some internal hacking tool that uses usbip just get leaked?

No one who we asked "why?" when they submitting these issues would give a very clear answer to that simple question so something is going on...

It was one of those Mondays... https://lwn.net/Articles/1059031/

2026-02-16T21:14:08Z

It was one of those Mondays...

https://lwn.net/Articles/1059031/

Another post in my series about the kernel CVE process, all about ...

2026-02-16T13:54:59Z

Another post in my series about the kernel CVE process, all about how we classify fixes to be assigned a CVE and other related things:

http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/

All 5960 GSD kernel security reports are now finally processed ...

2025-12-30T14:36:47Z

All 5960 GSD kernel security reports are now finally processed and CVE ids have been assigned for those that meet the cve.org criteria. Only took me almost 2 years of manual review, ugh, that was a grind:

https://lore.kernel.org/r/2025123055-directory-hemlock-a282@gregkh

The kernel CNA assigned their 10000th CVE last week, ...

2025-12-28T12:29:17Z

The kernel CNA assigned their 10000th CVE last week, CVE-2025-68750

So far the “stats” look like:

Year Reserved Assigned Rejected A+R Returned Total
2019: 0 2 1 3 47 50
2020: 0 17 0 17 33 50
2021: 0 732 24 756 16 772
2022: 3 2041 47 2088 0 2091
2023: 1 1464 47 1511 0 1512
2024: 6 3069 96 3165 0 3171
2025: 73 2421 39 2460 0 2533
Total: 83 9746 254 10000 96 10179

Note, the “year” is the year the bug was fixed in the kernel tree, NOT the year the CVE was applied for/assigned.

Rust is is not a "silver bullet" that can solve all ...

2025-12-16T16:09:42Z

Rust is is not a "silver bullet" that can solve all security problems, but it sure helps out a lot and will cut out huge swatches of Linux kernel vulnerabilities as it gets used more widely in our codebase.

That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.

Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase, so as always, everyone should be upgrading to newer kernels to remain secure overall.

Starting to write up a series of articles about the Linux kernel ...

2025-12-09T04:43:28Z

Starting to write up a series of articles about the Linux kernel CVE work that has happened in the past 2 years, starting with some "back to basics" information about how Linux kernels are numbered as many people/companies really don't know how we do this, and it matters a lot in tracking bugfixes and how to determine "vulnerable" and "fixed" kernel releases:
http://www.kroah.com/log/blog/2025/12/08/linux-cves-more-than-you-ever-wanted-to-know/
and
http://www.kroah.com/log/blog/2025/12/09/linux-kernel-version-numbers/

The European Union has now published a great page about the Cyber ...

2025-12-03T13:10:46Z

The European Union has now published a great page about the Cyber Resilience Act that contains a 66 page FAQ about lots of things in "plain english": https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation

The last 5.4.y kernel release has now happened: ...

2025-12-03T12:58:24Z

The last 5.4.y kernel release has now happened: https://lore.kernel.org/all/2025120319-blip-grime-93e8@gregkh/

Please don't use this branch anymore, it's really old, and pretty obsolete, and has over 1500 unfixed CVEs in it:
https://lore.kernel.org/all/2025120358-skating-outage-7c61@gregkh/

And if you are stuck with that kernel version for some reason, go ask your vendor to fix those 1500+ CVEs, otherwise you are paying for support that doesn't actually do anything for you...

It has now been 0 days since a AI-hallucinated "security ...

2025-11-21T14:46:41Z

It has now been 0 days since a AI-hallucinated "security report" was sent to the kernel security team.

Right now we seem to be averaging about 1 per week, not bad overall probably compared to other projects.

To be fair, a real security bug was recently found with an "ai tool", but the authors of that at least took the time to verify it was real before sending it to us, and they provided a patch, so not all is doom and gloom.

Benchmarking the different machines in my office with the ...

2025-10-01T20:38:57Z

Benchmarking the different machines in my office with the wonderful kcbench: http://www.kroah.com/log/blog/2025/10/01/the-only-benchmark-that-matters-is.../

Long and fun interview with me on the Wookash Podcast just got ...

2025-06-08T07:51:27Z

Long and fun interview with me on the Wookash Podcast just got published: https://www.youtube.com/watch?v=-1-OjxPJZcs

My seat name tag for the EU CRA meeting today... ...

2025-06-04T07:58:37Z

My seat name tag for the EU CRA meeting today...

Given the news of the potential disruption of the CVE main ...

2025-04-16T07:14:12Z

Given the news of the potential disruption of the CVE main server, I've reserved 1000 or so ids for the kernel now, which should last us a few weeks.

Fun, but long, interview with me about how the Linux development ...

2025-03-19T21:16:04Z

Fun, but long, interview with me about how the Linux development process works was just released: https://newsletter.pragmaticengineer.com/p/how-linux-is-built-with-greg-kroah

It's not all boring, I talk about Rust and our lack of project managers (both good things IMO) so there's lots for people to be grumpy about if you are so inclined.

While I don't know if is the first time this has happened, ...

2025-02-14T15:36:34Z

While I don't know if is the first time this has happened, it's good to acknowledge this given all the crazy, odd, and incorrect press about Rust in Linux these days.

A new in-kernel api just landed in linux-next from my tree and should hopefully show up in 6.14 to make some kinds of drivers easier to write, that has a rust binding added at the exact same time:
https://lore.kernel.org/all/2025021023-sandstorm-precise-9f5d@gregkh/

Many thanks to Lyude and Danilo and many other Rust kernel developers for the help in creating the binding and make the C side work well for both Rust and C code at the same time. The end result here for any C developer alone, is much better off for all of their help.

For 2025, here is a updated and hopefully-useful notice about ...

2025-01-31T09:22:52Z

For 2025, here is a updated and hopefully-useful notice about Linux kernel security issues, as it seems like this knowledge isn't distributed very widely based on the number of emails I still get on a weekly basis:

- The Linux kernel security team does not have any "early notice" announcement list for security fixes for anyone, as that would only make things more insecure for everyone. The number of organizations that fail to understand this is way too high.

- The kernel community DOES assign CVEs, as we are a CNA, please see https://www.kernel.org/doc/html/latest/process/cve.html for how they are handled and assigned. Side note, we were #2 in quantity for CVE assignments in 2024 despite only doing so for 10 1/2 months, averaging about 10 CVEs per day. Any process you might have where you feel you need to research each CVE on an individual basis manually is going to be a major time suck, automate it! All CVE entries are provided with proper git commit ids for the vulnerable release ranges for you to check yourself, AND we have tools and other formats that you can use to check this yourself. See https://git.kernel.org/pub/scm/linux/security/vulns.git/ for the tools and raw data for you to pull from directly if you don't want to deal with the cve.org json feed.

- Kernel CVE entries are constantly updated over time, you can not just look a them only when created, and then ignore all updates. Too many groups are missing revoked CVE entries and tightening of vulnerable kernel ranges that we are updating on a weekly basis. By ignoring the updates, you are causing yourself more work, not less. cve.org provides an "updated" feed in their git tree, use it!

- Along the lines of the huge number of recorded CVEs, you HAVE to take all of the stable/LTS releases in order to have a
secure and stable system. If you attempt to cherry-pick random patches you will NOT fix all of the known, and unknown, problems,
but rather you will end up with a potentially more insecure system, and one that contains known bugs. Reliance on an "enterprise"
distribution to provide this for your systems is up to you, discuss it with them as to how they achieve this result as this is what you are paying for. If you aren't paying for it, just use Debian, they know what they are doing and track the stable kernels and have a larger installed base than any other Linux distro. For embedded, use Yocto, they track the stable releases, or keep your own buildroot-based system up to date with the new releases.

- Test all stable/LTS releases on your workload and hardware before putting the kernel into "production" as everyone runs a different %
of the kernel source code from everyone else (servers run about 1.5mil lines of code, embedded runs about 3.5mil lines of code, your mileage will vary). If you can't test releases before moving them into production, you might want to solve that problem first.

- A fix for a known bug is better than the potential of a fix causing a future problem as future problems, when found, will be fixed then.

@nprofile…lrh8 @nprofile…qfqs Maybe, maybe not. Please see my ...

2024-12-17T09:08:33Z

In reply to nevent1q…eyvx
_________________________

nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqqtjqahsnqzgpafv6a3dyjeq49l35jussjv988g5r69s326u6g4vsnrlrh8 (nprofile…lrh8) nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqcm7wlyhq6f0yhmert2lsm45s3ej26dl4whu2y8n4w04gqhg3ctxscjqfqs (nprofile…qfqs) Maybe, maybe not. Please see my old post here: http://www.kroah.com/log/blog/2021/02/03/helping-out-with-lts-kernel-releases/ for what drives all of this (hint, people actually asking that they need it AND providing the help to make it possible.)

"I'm probably not alone in thinking that sometimes the ...

2024-12-07T11:48:51Z

"I'm probably not alone in thinking that sometimes the compiler writers are doing their hardest to make life hard for people writing low level code." -- David Laight at: https://lore.kernel.org/r/344b4cf41a474377b3d2cbf6302de703@AcuMS.aculab.com

It's a fun thread, recommended for anyone who deals with compilers and trying to get them to do what you would think would be a "easy" thing to do and the hacks around them to get them to do that (hint adding "+ 0" to an expression tricks the compiler into doing what you meant it to do is usually a sign that something is wrong somewhere...)

The last 4.19.y kernel has been released: ...

2024-12-05T11:45:14Z

The last 4.19.y kernel has been released:
https://lore.kernel.org/lkml/2024120520-preorder-untracked-6e5b@gregkh/T/

Please move to a more modern kernel if you are somehow still running this one, which I strongly would not recommend doing.

New hardware showed up today, turns out Linux works just fine on ...

2024-12-04T13:58:22Z

New hardware showed up today, turns out Linux works just fine on it. Here's the 6.12.1 kernel running in Wayland.

Water bottle for scale.

@nprofile…5k85 Odd, works for me! How about this ...

2024-11-16T07:41:41Z

In reply to nevent1q…hcff
_________________________

Adolph (nprofile…5k85) Odd, works for me!

How about this https://github.com/gregkh/usbutils/security/code-scanning

And it's obviously picking up the temp files that meson uses for "does this compiler have this feature" but that's temp files, and not actually in the repo itself. Surely tools like meson are handled properly, right?

Dear lazyweb, For the usbutils project, developers have helpfully ...

2024-11-16T07:38:33Z

Dear lazyweb,

For the usbutils project, developers have helpfully set up a bunch of github actions to help with build tests and the like, and it also includes github's "security scanning" toolsets. Unfortunately the output of such tools is pretty useless and unhelpful to a fault.

Example, this "result": https://github.com/gregkh/usbutils/security/code-scanning/2291
which claims "short global name" yet there is no such actual global variable `i` in the codebase at all.

Because of stuff like this, the tools "claim" there are 63 "security" issues in the usbutils project. Since when did using single character names become a security issue, even if we were doing that, but ok...

So, how to turn this off, or better yet, fix the test to not report issues that are actually in the tests themselves?

Finally converted usbutils over to meson from autotools. Odds are ...

2024-09-02T19:13:49Z

Finally converted usbutils over to meson from autotools. Odds are I messed something up, so I should do a release soon to see what broke in the distros as I have no idea how they package this thing anymore:
https://git.sr.ht/~gregkh/usbutils/commit/86dcab8964901d15b87b156546559c8ae28bd9fe