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

@gregkh Yeah I was going to guess it has something to do with 38,640,000 lines of code. And the fact you actually fix things quickly.

@kurtseifried It's not like we weren't doing this before Febuary, we were, our rate of fixing hasn't changed at all from what I can tell.

Here's a good summary of the talk from @sjvn : https://www.zdnet.com/article/dont-panic-its-only-60-linux-cve-security-bulletins-a-week/

@gregkh @sjvn that’s what I mean, your code base is big and it’s dynamic. I’m trying to think of another code base as big as yours that’s also as dynamic as yours and nothing is really coming to mind.

@gregkh @sjvn also now you have me thinking about the metric of lines of code used. For example, there must be projects where I’m guessing very little of the code is actually used by anyone at all, eg it has a lot of unused features, or legacy support that isn’t needed but hasn’t been removed. And then I’m guessing there’s more common case of very few people use a given code path but like any feature if one percent of the internet uses it that’s a lot of users.

@gregkh World would be better place if you did less talks and more research before marking non-security-related bugs as CVEs.

@gregkh “If you are not using the latest stable / longterm kernel, your system is insecure” ... I like that one. Thanks!

@gregkh Nice.... One thing I'm curious though, if security issues are handled by a small team and reviews are public, wouldn't it be possible for a threat actor to watch patches coming from this group and assume most of them are security issues? There would be a lot but after filtering for commonly used subsystems/drivers and indicators of possible remotely-accessible bugs it would be feasible to investigate and try to exploit them, no?
1/2

@gregkh Yet as I was writing this I realize the alternative is also scary, if issues are reviewed internally (perhaps a larger group but still tightly controlled), then any commit not seen in the ML's are definitively security issues - that reduces the lead time (those commits could be merged shortly before cutting a release) yet reducing the time between merge and release also limits the ability for related issues to be reported.
2/2

@gregkh So I guess it's the right approach, but how much off an issue could that be?

@dermoth All of those commits we are reviewing are already public and have been for weeks, to somehow think that the "bad guys" are not watching our commit stream as-it-happens is to imply that they don't know what they are doing :)

So there is no benefit or need to be "private" about tagging specific commits as CVEs before we do so as you should have already taken all of these fixes weeks ago anyway.

@gregkh I'm not sure if I fully understand the "but once it is fixed, it becomes irrelevant" in the slides. In the optimal case, yes, I agree.

But what if it is a "boomerang bug"? If people misunderstood the issue and created a wrong or only partial fix? What if the fix later turned out to create a regression somewhere else? Wouldn't it be helpful for others to know how to recreate the original issue to be able to create a proper fix then?

(And how often do "boomerang bugs" occur in Linux?)

@gregkh one example I'm thinking of is this bug in the Linux bridge which I tried to fix more than ten years ago... and then this year noticed I didn't properly fix it... having described the original issue and how to trigger it in the Git commit greatly helped me to remember the original issue and what it was all about in the 1st place...
2013: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b00589af3b04736376f24625ab0b394642e89e29
2024: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5c3eb4b7251baba5cd72c9e93920e710ac8194a
(would hv said the issue were not a sec. issue / not crit. but after your slides not sure anymore)