Linux CVEs, more than you ever wanted to know

pedrozieg an hour ago | parent | next [-]

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.

▲

1vuio0pswjnm7 7 hours ago | parent | prev | next [-]

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

▲

paulryanrogers 11 hours ago | parent | prev | next [-]

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

▲

dredmorbius 11 hours ago | parent [-]

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

	▲	paulryanrogers 7 hours ago \| parent [-]
		Perhaps I misunderstand, but aren't those far above the "So here’s a series of posts" and its bullet list?

▲

throw329084 11 hours ago | parent | prev [-]

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

▲

accelbred 5 hours ago | parent | next [-]

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.

▲

TheDong 6 hours ago | parent | prev | next [-]

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 3 hours ago \| parent [-]
		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

▲

DeepYogurt 8 hours ago | parent | prev [-]

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

	▲	spockz 2 hours ago \| parent [-]
		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.