← Feed

Posts

• Post #4355636

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

• Post #4239050

  Another one of those mornings....

• Post #3554061

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

• Post #2175385

  Here is a 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 get on a weekly basis: - The 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 kernel community does not assign CVEs, nor do we deal with them at all. This is documented in...

• Post #2171011

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

• Post #2110070

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

• Post #1984268

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

• Post #1881239

  My build system right now, as it's one of "those" mornings....

• Post #1636946

  As people keep guessing what/who `gkh_clanker_t1000` is: https://lore.kernel.org/r/20260424054143.087847e1617a84df8b501313@linux-foundation.org here it is after I cleaned up some of the horrid cable mess that had grown up around it.

• Post #1579030

  After 25+ years of kernel development, I was finally forced to touch `mm/` and it was due to a nommu "issue": https://lore.kernel.org/lkml/2026042334-acutely-unadorned-e05c@gregkh/ As @axboe@fosstodon.org said the other day, we aren't expecting a box of chocolates: https://lore.kernel.org/r/2f2c91cb-f20e-44eb-8ba3-2d5b3d649642@kernel.dk but these past weeks have made me feel like someone owes a few of us kernel developers a bunch of whisky at the very least...

• Post #958827

  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/

• Post #958825

  Posting this link here, as I always have to dig every few years when I need it: https://cdecl.org/ a C -> English translator for those "fun" const pointer to const array issues that you have to work out every so often...

• Post #958820

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

• Post #935211

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

• Post #611764

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

• Post #511718

  After talking with a bunch of different companies / groups, we've now bumped the length of a few of the longterm kernels we are supporting: https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=d04587da86a3464881e0c97aabddd2c271105698 As always, the dates can be found at:https://www.kernel.org/category/releases.html

• Post #337547

  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/

• Post #315121

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

• Post #184092

  Prediction for the potential future: When the AI coding agent companies are just about to run out of money, down to their last few % raised as none of their customers are actually paying the real cost required to run these services, they pivot and take all of the uploaded code that was willingly sent to them, turn it into thousands of products / services to sell / rent, disconnect the public api endpoints leaving their old customers helpless as they no longer remember how to program "in th...