Notices by Greg K-H (gregkh@social.kernel.org), page 2
-
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 03-Sep-2024 14:05:49 JST 
Greg K-H
@lanodan Ah, a hold-over for when I was messing around with the cflags. I'll work on adding proper support for more flags and then that variable will be used.
Thanks for taking a look! -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 03-Sep-2024 04:25:48 JST
Greg K-H
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 -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 27-Aug-2024 22:55:50 JST
Greg K-H
@kurtseifried Note, 3000 includes the "old" things we are backfilling from the GSD database, not just the ones that have shown up this year since we started in February. So while 3000 sounds big, if you are using a modern kernel (i.e. something from this year), it's only 1500+ issues to be assigned so far.
Sorry to nit-pick, just wanted to be specific as 3000 in 6 months originally seemed like a lot to me before I went back and looked at these numbers.
Also, for those who want to play along on their own, just clone our vulns.git repo at git.kernel.org and look at the information directly there yourself, it's all being reviewed and assigned in the open, unlike other projects... -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 27-Aug-2024 22:55:49 JST
Greg K-H
@kurtseifried That's a really good point, the "open source" ecosystem being a CNA is very new, I don't think this was even possible until less than a year ago when python blazed that trail.
And it's nice to see we aren't alone here with "big numbers", it's going to be an interesting thing to watch shake out as "take responsibility" rules/laws come into being in different locations. I agree with you in that the quantity is just going to get larger over time. -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Thursday, 22-Aug-2024 09:01:21 JST
Greg K-H
Here's a link to the slides for my "Why are there so many kernel CVEs?" talk I gave at OSS China yesterday:
https://kccncossaidevchn2024.sched.com/event/ed2b39a9a0cdfc1df18de67ce0c2f6be
Link to git repo for the slides if the schedule site acts odd for you:
https://git.sr.ht/~gregkh/presentation-security
It was fun, and will be the "set up" for my Kernel Recipes talk in Paris in a few weeks (only 3 conferences to go between now and then, travel is back in full swing.) -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Friday, 21-Jun-2024 08:45:03 JST
Greg K-H
@killyourfm If you ever need a guest, I'll be glad to do so, keep up the great work! -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 08-Jun-2024 19:48:31 JST
Greg K-H
@kurtseifried @anant @joshbressers @adamshostack @camdoncady @dangoodin Thank you for noticing, I spent a lot of time on making this information able to be created automatically as it is quite valuable for people to be able to EASILY, and programatically, determine if they should, or should not, even look at this specific entry. Everyone does actually know what small % of the 80,000+ files in the kernel they build into their image, and what versions they are running, right? If not, they have bigger issues than random CVE entries...
Side note, I create all the json from a set of wonderfully horrible bash scripts that parse the semi-free-flowing kernel git commit logs and branches to determine the information needed:
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/bippy
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/dyad
https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/id_found_in -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Thursday, 30-May-2024 19:27:26 JST
Greg K-H
@vbabka @mort @ljs @mcepl I am not trolling anything, I am working within the requirements of the CVE system at the request of the people who run it. We are doing so because other entities were abusing the CVE system for the Linux project in the past, so in order to take control of it, we must work within the constraints with which we are placed.
And that means assigning CVEs to everything that meets the definition of vulnerability as defined by cve.org. If you, or anyone else notices a CVE we issue that does NOT meet that definition, please let us know and we will be glad to reject it.
Odds are other operating system kernels will start doing the same as Linux does, if they wish to be a CNA for their project. We aren't alone here, it's just that we report our fixes, others don't, or aren't actually developing any fixes. You be the judge of which is the case for various projects :) -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Thursday, 30-May-2024 19:27:25 JST
Greg K-H
@ljs @mcepl @mort @vbabka Yes, I said "trolling" many years ago in jest as there was no way for the kernel community to actually create CVEs like that, it was a joke.
But what I'm saying now is that I am NOT trolling anyone. The number of CVEs created for the kernel is exactly what cve.org wants us to do here as now we ARE allowed to be a CNA. And by being a CNA, we must follow the rules of cve.org which is what we are doing. I have had many meetings with the cve.org employees and board about this, and everyone seems to be in agreement that what we are doing now is correct and should be done this way.
Again, I'm not trolling anyone, and again, the kernel development model has not changed, all that has changed is that finally we are marking all potential vulnerability fixes as CVEs.
Again, if anyone knows of any CVE entries that we have assigned that should not be CVE entries, please let us know. -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Friday, 17-May-2024 16:14:14 JST
Greg K-H
@vegard @kernellogger "a team of engineers" COULD do that (hint, Android does, by just taking the stable updates), but the paper shows that a specific "team of engineers" currently does NOT do that, which puts the users of those kernels potentially at a greater risk.
Read the paper, it's interesting.
Disclosure, I read it before it was published, but had no influence on it at all. -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Thursday, 02-May-2024 02:42:18 JST
Greg K-H
@kees @vegard @corbet @kernellogger They are? news to me :)
We start out at 2, and then after a year see what companies need/want/desire and are willing to work for having a longer period. Right now 2 years is rough, so we're doing longer.
Ideally I'd love to only do 2 years, maybe next year? Or it not, the year after that? I'm not going anywhere, we'll get there eventually as people learn that attempting to keep a fixed release on top of a highly moving project with thousands of fixes a month, is not a good idea for a variety of reasons... -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Thursday, 02-May-2024 02:42:16 JST
Greg K-H
@vegard @monsieuricon @kees @kernellogger @corbet The FAQ says the situation, I don't know why people are confused, nothing has changed in a while.
You aren't alone, Linaro had a whole "webinar" about how the world is in trouble now that LTS releases are only 2 years, despite my objections directly to them that "this is not the case".
Oh well, what do I know... -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Friday, 08-Mar-2024 21:36:12 JST
Greg K-H
@larsmb @vegard @pavel @kernellogger I find it hard to understand how this is an "attack", when it was specifically authorized and endorsed by the CVE employees and board of directors? They knew exactly how many CVEs we would be filing on a weekly basis and how we would be evaluating them for inclusion. We went through many meetings and discussions before our application was accepted and our id submissions were allowed.
They also asked us to backfill the database with our previously submitted GSD information, as well as everything that gets merged forward. That backfill work is ongoing and is the large volume of what is currently being assigned right now. That information has already been out there for years in GSD, putting it in CVE doesn't change the actual kernel commits or "security" at all, it's just that you might not have noticed the GSD entries (hint, the "bad guys" sure did...)
The number of "new" CVE entries is a small % overall as we really have only processed the changes from v6.7.0..v6.7.3 or so. We are behind in the new stuff and will catch up soon there, help is always appreciated, if you see a commit you want assigned a CVE, just ask!
As others have said, this hasn't changed how the kernel commits are merged at all, it's just calling stuff out that everyone should have already been looking at and merging already, with way more meta-data and information than has ever been done before for kernel CVEs, thereby actually raising the information level in the CVE database here (which is probably why the CVE board wanted this.)
If companies are somehow dictating that they MUST look at and evaluate all CVEs, then they should be happy as many groups were intentionally abusing the CVE process for the kernel previously, making their life much more difficult (including the community's life, which is why we became a CNA.) That abuse has now stopped, to be replaced with a different workflow with way more meta-data produced to help make decisions easier. So far one of the biggest complainers was the company that was doing that abuse as they are no longer allowed to do that (to be specific, that was NOT SuSE). -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Friday, 08-Mar-2024 21:34:56 JST
Greg K-H
@vegard @ljs @kernellogger @larsmb @pavel "security impact" means you have to take into account your specific use case, and we have no idea what your use case is Remember, Linux is in cow milking machines, servers, helicopters on Mars, phones, utility meters, watches, mega-super-yacht-stabilizers, wind turbines, printers, cars, planes, trains, and more. Doing an accurate "security impact" is going to be different for all of those cases.
To quote Ben Hawks, "It's hard to capture the fact that a bug can be super serious in one type of deployment, somewhat important in another, or no big deal at all -- and that the bug can be all of this at the same time. Vulnerability remediation is hard."
His full post is worth reading: https://blog.isosceles.com/what-is-a-good-linux-kernel-bug/ -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Friday, 01-Mar-2024 21:58:10 JST
Greg K-H
@clacke @joshbressers @kurtseifried @ljrk Yes, that is a good overview, and you can point at the managers and developers on the Google Android team for doing all of this hard work both in convincing people that this was a good idea, and actually doing the work to get stuff merged properly. I've watched them do this for the past 10+ years, it wasn't easy but has paid off a lot in my opinion, the security level of an Android device is worlds better than it used to be because of this effort. -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Wednesday, 28-Feb-2024 02:46:47 JST
Greg K-H
@matttbe @kernellogger We've been on irc for decades, we are everywhere :) -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Wednesday, 28-Feb-2024 02:46:38 JST
Greg K-H
@gromit @kernellogger @matttbe #kernelnewbies is great, I've been on there for a _very_ long time. -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 27-Feb-2024 14:54:50 JST
Greg K-H
@ljrk @kurtseifried @joshbressers It does not affect anything at all about in-kernel apis, there is no such stability rules or requirements, rather the opposite. -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 27-Feb-2024 14:54:48 JST
Greg K-H
@ljrk @joshbressers @kurtseifried Based on the Android work I've seen happening, I doubt it. We have successfully run Pixel6 on every Linus -rc release for the past 3 years and that had 300+ out of tree drivers, not an issue. If you want to keep your code out of tree, you can, it just costs you money to do so, which companies have long understood for many decades now, it's their business decision. CVEs aren't going to change this at all, it does not affect the rate-of-change of upstream and stable releases at all. -
Embed this notice
Greg K-H (gregkh@social.kernel.org)'s status on Tuesday, 27-Feb-2024 14:54:46 JST
Greg K-H
@ljrk @joshbressers @kurtseifried The core Android portion of Google is very much NOT out-of-tree, they merge their code upstream almost always first before applying it to older Android kernel branches. See the yearly report at the Linux Plumbers conference for the past 5+ years where they what has been merged, what is left to be merged, and what is coming next, with pretty graphs and the like.
They have a strong "Get your changes upstream first" rule with their OEMs and you can see the interactions with those companies uptream has increased dramatically over the past years been because of this.
ChromeOS portion of Google also has a strong "upstream first" rule, and is very good about taking updates and getting changes merged properly.
The Pixel out-of-tree stuff is due to other "reasons", but that is a separate division and there have been many patch submissions recently upstream to resolve that delta, so that is being whittled down.
All GNU social JP content and data are available under the