The Linux kernel giving CVEs to all bugfixes is sort of predictable | Hacker News Reader

The Linux kernel giving CVEs to all bugfixes is sort of predictable

utcc.utoronto.ca

36 pointszdw13 comments

CVEs being issued willy-nilly (both inside and outside the kernel community) makes me think of the modern US Patent Office. It's too difficult and expensive to neutrally examine the deluge of incoming candidates (and nobody really wants to pay for all that expertise), so instead we just grant them all, and then it's someone else's problem.

Another tragedy of the commons.

It's not tragedy of the commons for the simple reason that it is the creators of the project that're issuing the CVEs. If anything, it was the prior situation that was the real tragedy of the commons- the freeloaders were not contributing resources back to the Linux developers for security assessment.

Now everyone gets to do their own, which they should have been doing in the first place.

But is the system really working usefully in this case? It seems like the intended purpose of CVEs is to actually identify serious (and less serious) exploits, which requires that someone, somewhere do quite a lot of work figuring that out and keeping track of things. But the kernel maintainers didn't sign up for that, so they basically shut things down via malicious compliance--not that I blame them, since nobody is stepping up to do the work and the maintainers already have a job, thank you.

So the tragedy of the commons is that security organizations ended up relying on CVEs as a security standard, without really thinking through who was going to do the dirty work of keeping that system going as it expanded.

> the intended purpose of CVEs is to actually identify serious (and less serious) exploits

No. It was created for cross-referencing different vulnerability databases.

https://www.tripwire.com/state-of-security/history-common-vu...

<quote> There’s just one problem – each security vendor has its own database with little to no crossover. Each vendor’s tool generates its own alert for detected vulnerabilities, and these alerts must be manually cross-referenced between the tools to determine if they are separate issues or multiple alerts for the same issue. </quote>

Some people wanted CVEs as identifiers. Some wanted the CVE most to be dense with actual security bugs (that justified backports, upgrades etc). Some wanted to issue many, often with nice names.

Pick two uses, can't have all three.

Hopefully with better LLMs, the patent office can judge patent applications better, and search for prior art better as well.

This does seem like the pretty obvious and inevitable outcome. Determining if a bug fix has security implications and if so how severe they are is often very difficult and all that you can confidently say is that you don’t know how to exploit it. Downstream consumers have tried to pressure the kernel maintainers into deciding which fixes need to be backported by demanding CVEs, but now they’re running into the problem of that they didn’t actually ask for the thing they really wanted since they knew that request would be (and has been) denied.

Yeah the 3rd party "we have an old tree and want to maintain it so you need to do extra work to support us, and only us, despite us being the ones getting paid" is obnoxious (the reason for maintaining old kernels seems to be invariably a product developer selling products for money, or a value "adder" providing long term "support" for old kernels in exchange for money - and we see here wanting to outsource the actual work for that to the unpaid upstream devs).

That said this seems entirely predictable to me, and I'm surprised the author did not simply assume that this would be the outcome given how this nonsense plays out:

  * If kernel devs adopt "only security bugs get CVEs" the devs get dragged over coals if they ever don't classify a bug fix that turns out to have security implications

  * What do kernel devs do when they land an architectural change that happens to fix security bugs?

  * How do you expect them to handle people just watching every fix, who then decide one is a security fix, and give it a webpage and press release when there was no CVE?

There's also the fun edge case: the people demanding extra free work from others are wanting to support old kernels as cheaply as possible, but a bug fix in a current kernel may just be a bug fix, while in old kernels the lack of subsequent work in the kernel could mean they're security vulnerabilities. If only "security" bug fixes are meant to get CVEs then either developers have to in essence back port the change and see if the old behavior in the old kernel led to a security vulnerability, or assume all fixes could have security implications in out of date kernels.

i think it's fine (in concept) to have a central(-ish) numbering scheme for security bugs. so far, so good.

but this is made worse in no small part by security researchers, students, companies etc. are all using a CVE as an achievement or some kind of feather in their cap.

now, you get thousands of "CVE-2024-10340494: water is wet" and the related "CVE-2024-10340495: if users look up in the rain, they could conceivably drown". of course it would always also have a blog, a custom domain-name, a catchy title/nickname, etc.

it's Goodhart's Law in action: "when a measure becomes a target, it ceases to be a good measure."

and what else could the Linux devs reasonably do? it was either this or ignore CVE's entirely.

The CVE system was designed for cross referencing different database, not as a metric.

https://www.tripwire.com/state-of-security/history-common-vu...

True but irrelevant.

i totally agree that was what it was designed for

That pizza shop that responded to yelp trying to bully them by telling everyone to give them bad reviews.

Reply on news.ycombinator.com