Greg K-H

https://social.kernel.org/users/gregkh

Public Key

npub1zqk3v0zd7wsc57tz8zs539ec8vf9wsj7hel02j6hxrwwzkwnlvrsq83mrl

NIP-05 Address

gregkh_at_social.kernel.org@momostr.pink

Profile Code

nprofile1qqspqtgk83xl8gv2093r3g2gjuurkyjhgf0tulh4fdtnph8pt8flkpcprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmnt5z70q7

Publishing to

relay.momostr.pink

Author Public Key

npub1zqk3v0zd7wsc57tz8zs539ec8vf9wsj7hel02j6hxrwwzkwnlvrsq83mrl

Show more details

Last Notes

2026-08-03 13:31:13 UTC

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

2026-05-03 06:23:28 UTC

@npub16g6…s9jn I will quote this in many presentations in the future because it is so true:
"The Kernel assigns lots of CVEs. They say it’s because they don’t really know how the Kernel is being used, so they err on the side of caution. Companies hate this because they have to deal with a lot of CVEs. Does the Kernel do this because it’s easier or do they have some sort of secret nefarious reason? Probably because it’s just easier and they have zero downside to disclosing and moving on. "
#note1975…2axy

2026-05-01 08:16:54 UTC

- reply

I love it how people think that "coordination of vulnerabilities" is actually something that can be done these days. Think of just who uses the software in question, and who should, and should not, be on such a list to get a "early disclosure notification".
As I have said for quite some time now, all early-disclosure lists are leaks, otherwise why would your government allow them to be in existence?
Software, and specifically open source software, runs the world. So should the whole world be on that notification list? :)

2026-04-23 12:34:44 UTC

- reply

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

2026-04-23 12:12:17 UTC

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

2026-04-06 10:21:26 UTC

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

2026-03-31 13:47:55 UTC

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/

2026-03-30 06:49:43 UTC

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

2026-03-27 09:26:55 UTC

- reply

It is real, see my interview in the Register today about this very problem: https://www.theregister.com/2026/03/26/greg_kroahhartman_ai_kernel/

2026-02-16 21:14:08 UTC

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

2026-02-11 09:49:08 UTC

- reply

If you want a CVE for your CV, come fix a Linux kernel bug! We are giving out 13 CVEs a day, plenty to go around for everyone! :)

2026-02-07 07:35:41 UTC

Looks like the AI companies have finally run out of money as they are asking various open source projects to test their closed source products for them for free. What could go wrong with giving access to an unknown tool to private code repos?
If I didn't know better, I would think this is an elaborate phishing scam, or they have run out of data to scrape and need more training material.
Gotta admire their brazenness...
https://media.social.kernel.org/media/84807b046eac8f56458134f8cb702bb885ab16f63dcba00cc758701a35e79ac7.jpg

2026-01-30 06:11:34 UTC

@npub1cm0…enqe It was an amazing honor to receive this, thank everyone so much, and for your great speech at the event.
#note1hu4…9a4z

2026-01-02 15:00:03 UTC

Another post in my Linux kernel CVE process series, "How the Linux kernel security process works": http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/

2025-12-28 12:29:17 UTC

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.

2025-12-16 16:09:42 UTC

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.

2025-12-09 04:43:28 UTC

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/

2025-06-04 07:58:37 UTC

My seat name tag for the EU CRA meeting today...
https://media.social.kernel.org/media/1cf2ce6ef522658d5cb63bc5f08aea5490eaf1e358ee6e7b42cb290c17dbf3db.jpg

2025-04-16 07:14:12 UTC

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.

2025-01-27 13:10:54 UTC

Scariest cable I have that I actually use. It's a USB-C to Thinkpad "adapter" that I bought to power a thinkpad that shipped with a giant 135W brick-of-a-power-supply. This cable does work, but has the tendency to "overload" many USB chargers, causing them to reset. Fun times, but good for traveling so I don't have to lug the brick around with me as well.
https://media.social.kernel.org/media/6f7f936f6cc23c13cf4f5862d2c7555dce2627cf7d5df9682c063d9af11d4ba8.png

2024-09-13 12:19:48 UTC

This "untrusted data" patch series from Benno Lossin is the result of conversations at last weekend's Rust Linux kernel conference in Copenhagen:
https://lore.kernel.org/all/20240913112643.542914-1-benno.lossin@proton.me/
It's not a "silver bullet" for why we should be using rust in the Linux kernel, but it is a "big giant sledgehammer" to help squash and prevent from happening MANY common types of kernel vulnerabilities and bugs (remember, "all input is evil!" and this change forces you to always be aware of that, which is something that C in the kernel does not.)
I had always felt that Rust was the future for what we need to do in Linux, but now I'm sure, because if we can do stuff like this, with no overhead involved (it's all checked at build time), then we would be foolish not to give it a real try.
And yes, I've asked for this for years from the C developers, and maybe we can also do it there, but it's not obvious how and no one has come up with a way to do so. Maybe now they will have some more incentive :)