So far this year the Linux Kernel has done 3000 CVEs even. This means we can expect roughly 4500 for this year in total. Bu I have good news: they only started in Feb so we can expect another 10-15% on top of that for 2025, so with any luck that'll be about 5000. In other words 12.5% or so of TOTAL CVE activity.

So when @gregkh says run current, you need to listen.

You can spend several thousand hours a year trying to triage Linux Kernel vulns, or you can invest that effort into automation (updates, builds, testing, etc.) and stay current and answer "did you fix CVE foo" with either a "yes" or a "that will go out in the next update at future time X".

@kurtseifried @gregkh or, you know… just don’t run Linux.

@kurtseifried Yeah, it's only about 60 a week, a bit more than I originally guessed, but not out of the expected range at all.

@mathaetaes @kurtseifried No one is forcing you to! But note, if other operating systems are not reporting these same types of numbers, then they just aren't reporting things that actually get fixed, or nothing is being fixed at all in them. It's up to you to determine which is the case for those systems :)

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

@kurtseifried @gregkh isnt that partly because the kernel devs are kinda trolling the cve community (or rather the weird corpos profiting of the community)?

I mean, every kernel bug is worth a cve, just update your stuff and you dont need to "manage your vulnerabilities"

@gregkh @kurtseifried @mathaetaes this must be a troll or a case of survivorship bias

A CVE does not mean a high risk. Companies should upgrade only when it's worth it, not only because there are known defects that could potentially be exploited. I totally agree companies should invest in automating upgrades, but not because there are many CVEs and always evaluating cost vs benefit.

@brahms @kurtseifried We are not "trolling" anyone, we are doing explicitly what the CVE.org board and staff have required us to do in order for us to be a CNA.

@gregkh @mathaetaes @kurtseifried Yeah, other operating systems actually do the sane thing of only reporting security bugs as CVE. Greg decided to be "special" :-(.

@gregkh @kurtseifried just to clarify: wasnt meant in a negative way.

This is something you have to do (as you made clear in your post back then), I personally just think that it is mostly work for you with little gain. The "trolling" was more a reference to the "every bug is a bug, [so its also a cve]" philosophy resulting in a huge amount of cve`s being created, maybe not the best wording on my site :s

@kurtseifried @gregkh that's ten CVE per day? 🤯 I know the kernel is a complex beast but that number feels totally bonkers

@gregkh actually 3000 is not a lot. I’m looking at the data and there’s some interesting trends with other CNAs.

There’s also also two CVE ecosystems now: the open source and the closed source. Most People are used to dealing with the closed source involves applying patches, made available by the vendor products that they have deployed.

But now they’re having to deal with the open source, and they have to do their own homework as it were, figuring out if they use this source in anything ( they likely have because of dependency chains), and remediating it on their own.

@brahms @gregkh again no that’s not how it works. You can actually get it straight from Greg when he was on the #osspodcast https://opensourcesecurity.io/2024/02/25/episode-417-linux-kernel-security-with-greg-k-h/

@kurtseifried While I can agree with "run current", note that as of now, my understanding is that *every* kernel bug gets a CVE. Every single one. No matter how remote a possibility exploitation of it would be. So the number of CVEs assigned maps fairly well to the number of bugs fixed; not to the number of actual *known* security issues.

@mkj no that’s not how it works. You can actually get it from the horses mouth here: https://opensourcesecurity.io/2024/02/25/episode-417-linux-kernel-security-with-greg-k-h/

@jpetazzo @gregkh there are actually several CNAs doing the same numbers, it’s just that people are ignoring them.

@gregkh

@kurtseifried @gregkh

after talking with a collegue about it I realized that im not the target group for this change, so I most likely misunderstood the reasoning behind it!

i will get back after listening through the episode, thanks for the link!

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

@gregkh the differences up until about five or 10 years ago, everybody didn’t ship open source. Now they do and they’re getting to learn how it works.

Myself and @joshbressers assigned thousands of CVs while we were at Red Hat to open source, Probably somewhere between 8,000 and 10,000 over the years. Edit: but it didn’t really matter as much because all of our TVs didn’t have open source jammed in them. Or our cars. Or kitchen appliances…

@kurtseifried @gregkh @joshbressers I mean, they probably did, but we did not knew about it :D

@kurtseifried @joshbressers Your TV (i.e. all TVs) was running Linux for 15+ years now, it's always been there, just no one noticed...

@gregkh @joshbressers @kurtseifried exactly. It is just that it takes time to get all the vulnerabilities shoved in your face

@kurtseifried @gregkh I would assume "current" also applies to supported longterm kernels that get included in point release distributions like @alpinelinux ?

@gregkh @brahms @kurtseifried Don't feed the troll.

@kurtseifried in this regard, I wonder about the plan of companies such as Red Hat or Canonical selling long term support.

(note: I don't know much about their exact offering, I'm into embedded stuff, building everything from sources anyhow.).

@jbm people generally don’t buy Red Hat Linux. They buy or build software that runs on top of it. So it will be around forever. But it probably won’t be very exciting. Like IBM.