Linux CVEs, more than you ever wanted to know

http://www.kroah.com/log/blog/2025/12/08/linux-cves-more-than-you-ever-wanted-to-know/

by voxadam • 8 months ago

103 29 8 months ago

kroah.com

paulryanrogers2• 8 months ago

Looking forward to posts links in the series. This seems like a bit of a tease.

dredmorbius2• 8 months ago

2nd 'graph of TFA links five talks on the topic all within the past two years.

paulryanrogers2• 8 months ago

Perhaps I misunderstand, but aren't those far above the "So here’s a series of posts" and its bullet list?

throw329084• 8 months ago

This blog post, brought to you by the man who wants to burn down the CVE system https://lwn.net/Articles/1049140/

DeepYogurt2• 8 months ago

To be fair the CVE system can't even encode a version string

spockz• 7 months ago

Not sure whether this is a limitation of the scanning tooling or of the CVE format itself, it also cannot express sub packages. So if some Jackson-very-specific-module has a CVE the whole of Jackson gets marked as impacted. Same with netty.

TheDong• 8 months ago

One of the many people who know the CVE system is elaborately broken in many ways.

Please, tell me what issues you have with how the kernel does CVEs.

raesene9• 7 months ago

Not op but if you are looking for information on why sone people arent keen on the kernels approach to CVE management https://jericho.blog/2024/02/26/the-linux-cna-red-flags-sinc... might be of interest

thyristan2• 7 months ago

All the issues basically boil down to "nobody wants to do the busywork of CVE filtering, triage, rejections, changes".

As a developer, kernel or otherwise, you get pestered by CVE hunters who create tons of CVE slop, wanting a CVE on their resume for any old crash, null pointer deref, out of bounds read or imaginary problem some automated scanner found. If you don't have your own CNA, the CVE will get assigned without any meaningful checking. Then, as a developer, you are fucked: Usually getting an invalid CVE withdrawn is an arduous process, taking up valuable time. Getting stuff like vulnerability assessments changed is even more annoying, basically you can't, because somebody looked into their magic 8ball and decided that some random crash must certainly be indicative of some preauth RCE. Users will then make things worse by pestering you about all those bogus CVEs.

So then you will first try to do the good and responsible thing: Try to establish your own criteria as to what a CVE is. You define your desired security properties, e.g. by saying "availability isn't a goal, so DoS is out of scope", "physical attacker access is not assumed". Then you have criteria by which to classify bugs as security-relevant or not. Then you do the classification work. But all that only helps if you are your own CNA, otherwise you will still get CVE slop you cannot get rid of.

Now imagine you are an operating system developer, things get even worse here: Since commonly an operating system is multi-purpose, you can't easily define an operating environment and desired security properties. E.g. many kiosk systems will have physical attackers present, plugging in malicious hardware. Linux will run on those. E.g. many systems will have availability requirements, so DoS can no longer be out of scope. Linux will run on those. Hardware configurations can be broken, weird, stupid and old. Linux will run on those. So now there are two choices: Either you severely restrict the "supported" configurations of your operating system, making it no longer multi-purpose. This is the choice of many commercial vendors, with ridiculous restrictions like "we are EAL4+ secure, but only if you unplug the network" or "yeah, but only opensshd may run as a network service, nothing else". Or you accept that there are things people will do with Linux that you couldn't even conceive of when writing your part of the code and introducing or triaging the bug. The Linux devs went with the latter, accept that all things that are possible will be done at some point. But this means that any kind of bug will almost always have security implications in some configuration you haven't even thought of.

That weird USB device bug that reads some register wrong? Well, that might be physically exploitable. That harmless-looking logspam bug? Will fill up the disk and slow down other logging, so denial of service. That privilege escalation from root to kernel? No, this isn't "essentially the same privilege level so not an attack" if you are using SElinux and signed modules like RedHat derivatives do. Since enforcing privileges and security barriers is the most essential job of an operating system, bugs without a possible security impact are rare.

Now seen from the perspective of some corporate security officer, blue team or dev ops sysadmin guy, that's of course inconvenient: There is always only a small number of configurations they care about. Building webserver has different requirements and necessary security properties than building a car. Or a heart-lung-machine. Or a rocket. For their own specific environment, they would actually have to read all the CVEs with those requirements in mind, and evaluate each and every CVE for the specific impact on their environment. Now in those circles, there is the illusion that this should be done by the software vendors, because otherwise it would be a whole lot of work. But guess what? Vendors either restrict their scope so severely that their assessment is useless except for very few users. Or vendors are powerless because they cannot know your environment, and there are too many to assess them all.

So IMHO: All the whining about the kernel people doing CVE wrong is actually the admission that the whiners are doing CVE wrong. They don't want to do the legwork of proper triage. But actually, they are the only ones who realistically can triage, because nobody else knows their environment.

accelbred• 8 months ago

I, this last week, had to spend hours dealing with a fake CVE that was opened 2 years ago on an open source dependency of our project for a bug that amounts to "if you have RCE, you can construct a malicious java datatype and call this function on it to trigger a stack overflow". The github thread on the lib is full of the maintainers having to deal with hundreds of people asking them for updates on an obviously fake CVE. Yet the CVE is still up and has not been deleted. And I now get a request from a customer about fixing this vuln in our code their CVE scanner found.

The CVE system is broken and its death would be a good riddance.

some_random3• 7 months ago

The CVE system isn't great but it's all we have and demanding its destruction because a CNA didn't do their job (just like the Linux CNA, I might add) is childish.

1vuio0pswjnm72• 8 months ago

https://web.archive.org/web/20251210012827if_/http://www.kro...

styanax• 7 months ago

I'm mildly surprised GKH doesn't deploy SSL. In this day and age I just close the browser window when the http-only browser warning comes up and move on to something else.

1vuio0pswjnm72• 7 months ago

I dont use a popular browser to make TCP/UDP connections or HTTP requests over the internet

This group

https://cabforum.org/about/membership/members/

has no control over the software I use

I believe I can do better checks on who "controls" a domain name than Let's Encrypt. If I am the CA then I dont "trust" ad/tracking servers. But popular browsers do. Third party CAs are happy to take money from the people behind the data collection, surveillance and ad services that have ruined the web

I dont find anti-HTTP commentary any more convincing than anti-HTTPS commentary. Each user is different and is free to choose. Each is free to make their own decisions under whatever their own circumstances

For many years, cr.yp.to was HTTP-only

Popular browsers, TLS libraries and "Certificate Authorities" make heavy use of cryptography developed by the author of that site

Generally anyone who uses Linux makes use of software developed by the author of this blog post

Anyway, Tor is another TLS option besides using an archive

pedrozieg• 7 months ago

CVE counts are such a good example of “what’s easy to measure becomes the metric”. The moment Linux became a CNA and started issuing its own CVEs at scale, it was inevitable that dashboards would start showing “Linux #1 in vulnerabilities” without realizing that what changed was the paperwork, not suddenly worse code. A mature process with maintainers who actually file CVEs for real bugs looks “less secure” than a project that quietly ships fixes and never bothers with the bureaucracy.

If Greg ends up documenting the tooling and workflow in detail, I hope people copy it rather than the vanity scoring. For anyone running Linux in production, the useful question is “how do I consume linux-cve-announce and map it to my kernels and threat model”, not “is the CVE counter going up”. Treat CVEs like a structured changelog feed, not a leaderboard.

im3w1l• 7 months ago

Well consider this: Two projects with the same amount of actual security issues. one project is willing to say "this bug doesn't affect security" and is willing to take accountability for that statement. Another project is not willing to do so. As a result the former has a lower count and the other a higher count. Which is better for a user valuing security?

As the actual number of issues is the same you might say it doesn't matter, but I don't agree. As a user it is easier to deal with "here are the n issues", than "here are m things any n of which are real".

elric• 7 months ago

I recently attended a security training where the trainer had a slide showing how Linux has more CVEs per year than Windows. He used this as an argument that Linux is less secure than Windows. People lacking basic knowledge about statistics remains a problem. Sigh.

some_random3• 7 months ago

Unfortunately the security community is filled to the brim with incompetent schlubs chasing a paycheck and many of them find their place as trainers. Those who can't do, teach.

devwastaken2• 7 months ago

cybersecurity degrees are handed out everywhere to people completely unqualified. universities are scams.

Sohcahtoa82• 7 months ago

The problem I have is that the hyperfixation on CVE counts has turned the entire vulnerability management industry into Boy-Who-Cried-Wolf-as-a-Service.

99% of CVEs are essentially unexploitable in practice. If you're just concerned about securing your web apps and don't use WordPress, then the number of CVEs produced per year that you actually have to worry about is in the single digits and possibly even zero, yet Wiz will really love to tell you about hundreds of CVEs living in your environment because it's been a month since you ran "apt upgrade".

devwastaken2• 7 months ago

the reason we needed CVE is due to the fallacy of “99% are unexploitable”. memory and logic bugs are a time bomb. you dont need 1 big exploit, only a system that is put together poorly enough to have the bugs in the first place.

crest• 7 months ago

Is there a good public resource to figure out which parts of the kernel are the worst offenders e.g. is it a DoS in a driver for some ancient 8 bit ISA card or a remote code execution via ICMP echo requests?

letmetweakit• 7 months ago

shameless self promotion: I just launched a website [1] that tracks CVEs per kernel version since 2.6.12, it makes use of the tools that Greg KH will probably talk about in his next blog posts.

[1] https://www.kernelcve.com

some_random3• 7 months ago

The point of the CVE system is to alert downstream users of security bugs, and giving Linux their own CNA has resulted in a deluge of reports to end downstream users of bugs that are ultimately not security related and in that respect Greg et al have completely failed.

Linux CVEs, more than you ever wanted to know

Related Stories