>“Due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel… Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.”
https://docs.kernel.org/process/cve.html
"number of cves" is a useless metric, especially when it comes to the kernel.
If you're willing to stretch, missing but planned features also deny the use of said features since they haven't been added yet, and so are CVSS 1/Low vulnerabilities.
Resume-driven development for security researchers has never been easier!
That doesn't follow. In the extremely simple example, an adding service returning 1+1=3 has a bug, but it's not a possible DoS situation at all.
> missing but planned features also deny the use of said features
That's not what DoS is.
This whole situation with CVE assigning comes from the whole process being far from ideal. But it doesn't mean it's completely useless and doesn't follow any rules at all.
Until someone finds there is a user input they can trigger this bug causing some other bit of code to read data from the wrong offset and now it's a whole exploit.
Organizations that track their software and patch systems for CVEs have their own risk management system.
Publish xlow as low, we'll filter them out if we want to. As even they state in that article, they do NOT have the necessary context to filter stuff out. So why are they doing it?
What does this even mean? cURL is one of the most load-bearing pieces of software in existence. It, and the Linux kernel, which takes a similarly dim view of the CVE system, are the inventors. "Not Invented Here" seems to imply that there is a vast body of peer work for them to draw on to resolve this problem, but who are their peers? As far as I can tell, the answer is something like "Microsoft and Apple", on the one hand, who exist in a totally different, mostly closed-source or at least closed-development, ecosystem, or something like "glibc and OpenSSL" on the other hand, which have their own storied CVE history.
Is it really, or it's trivially replaceable by wget?
Regardless, even if hypothetical product X could do everything cURL and libcurl do for most people, that wouldn't make cURL/libcurl much less load-bearing, any more than the existence of FreeBSD or Illumos make Linux less load-bearing.
and one that will never make decisions that is incorrect or disliked by any party.
Resulting from miscalc of either stored or supplied would indeed create DoS.
If the off by one is in a graphical driver that causes an overflow leading to no output, that's DoS.
If the off by one is in the memory mapping of input devices leading to no available input, that's DoS.
Simple math is kind of everywhere in the kernel and userland apps. If the math is wrong and results in memory mapping wrong such that kernel panics or is unuseable, that's a breaking bug regardless of simplicity.
I'm using specific words and it's been explained and linked twice already. Come on!
However, the Linux kernel is supposed to run any userland program without crashing, so anything that crashes the kernel is a local DoS and there are a lot of them. It's also supposed to shield processes from each other and maintain privilege levels correctly, so many incorrect memory leaks are also CVE worthy. Whether a CVE applies depends on the people and programs using the kernel, and the kernel team can't read your code to tell you if it applies or not.
People reading CVEs wrong ("it's got a high number so we must patch within a day") must be going crazy over this, but the point of CVEs is to let you make judgement calls, not to be a cool statistic about how secure something is.
Most CVEs are irrelevant to most people, that's always been the case.
Unpatched bug, wrong color lights.
Yes, it is a bit of a stretch, I desperately hope programmable navigation lights are not a thing. And I also don't think every bug needs a CVE. But in the correct context nearly any bug could be critical.
Now this was a windows system[2] rather than linux but the point remains - if there was an external vulnerability in a crucial control system and this system was part of a network (eg to connect telemetry) then any exploit of that system could result in loss of life.
[1] https://www.computerweekly.com/news/1280091718/Chinook-compu...
After an assessment of the Fadec software the Superintendent of Engineering Systems said that the density of deficiencies was so high that the software was unintelligible.
There have been documented problems with Windows for Warships.
The vendors fixing them arguably prioritize these reports right. Most of the CVEs, even severe ones, are irrelevant in practice, and as parents note, are more like regular bugs with security flavor in reporting. The CVE label instead of regular bug tracking number makes them seem important.
Linux Kernel may be one of the few legitimate exceptions, indeed, due to the position in which it sits in the software stack. Also LLMs make previously unexploitable-in-practice vulnerabilities exploitable (by making targeted / personalized attack cheap enough to give them positive ROI), which complicates things.
But I think the most important thing to keep in mind is that a bug isn’t necessarily less serious or less important than a vulnerability. A serious bug should be patched just as urgently as a serious vulnerability.
Realistically, most admins cannot make judgment calls about 1000+ CVEs for a kernel release.
zero CVE policy = halt on business development.
Even more realistically, many admins do not have the background to be able to reason (by themselves) about the actual risk of most CVEs, so just going along with specialized media coverage is often a sound strategy.
We should keep our hopes up, someday we may get there.
Any patch that is back ported to a stable kernel, indiscriminately. And they have also started assigning CVSS scores with the same kind of malicious compliance.
Take for example, this patch in the device mapper RAID code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
After back porting to stable, it got assigned CVE-2026-89558 (which is in this list), and a CVSS score of 9.8:
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree...
Reasoning behind it being that theoretically, a RAID could be accessible over the network via NFS, iSCSI, etc... so if it gets corrupted, the buggy code path in the recovery (CVE-2026-89558) is effectively triggered over the network.
I do find it interesting though, that in the interest of transparency, every bugfix gets a CVE. Which ends up being a huge number… which will ultimately yield a more insecure environment as we’re getting conditioned to ignore/discount CVEs by the volume.
Over-reporting in this case seems to risk being counterproductive.
The frequency and severity of cyber attacks has increased to the point a much more cautious approach has become common. It's also easier to sell this work to management when you can point at the security tab on some tool and say "Look we need to patch these CVEs"
This isn't necessarily true, and will be less true in the coming age of LLM-automated vulnerability scanning. The version that you're downloading (after being nagged for a day) that adds Feature A may contain 3 vulnerabilities that are already known before you even download the update, and may or may not fix old vulnerabilities.
> [...] a much more cautious approach has become common.
I'd argue that this is a less cautious approach, not more. It takes time to carefully evaluate, review, and test each change.
Kernel development is well-funded, both via grants and by direct employment at big tech companies, and if they wanted to properly triage and annotate vulnerabilities, and provide reasonable assessments of what is or isn't likely to be a security risk, they absolutely could. They almost certainly could go to Google and say "we need two people full-time on your payroll for this" and they would get it.
I don't want to dunk on them too much because they're generally doing God's work, but these absolutist security stances are not worth being taken seriously.
It's basically saying that they can't possibly provide a valuable service for 99.999% of the install base because there might a hypothetical person out there using Linux in a really weird way. If Microsoft tried to make an argument like that, they'd get crucified.
Linux only ever wanted to promise support for the latest release and even Linux LTS is a concession.
And CVEs are basically a useless concept if you roll. (or at least not any more useful than any other bug tracker which supports tags)
If he kept true of his "we don't break user space" instead of it being "we don't break user space until we do and then it's on you to deal with it" perhaps more people would be willing to run the latest release.
Linux LTS is much more about proprietary drivers targeting a stable internal kernel API/ABI than about anything else.
Internal Kernel API changes all the time which can break proprietary drivers. But userspace API has a far higher guarantee.
I'll challenge this, I don't think that's really possible, at least not to any high degree of confidence. Nobody can realistically evaluate if any particular out-of-bounds read/write or use-after-free is "safe", and if you're going to consider all of those as security risks then there's not really a point in trying to filter out the few bug fixes that might not lead to those things.
Try going to the linked page, pick any random CVE, and read it. I've checked a bunch and I'd say _at least_ 8/10 of them are variations on those two things.
I would argue that it is more productive for the enduser as well. Not making a decision they cannot reasonably make is better then blindly believing in a decision that is likely wrong for your usecase.
:-P
The user may have no idea that the plugin is malicious; the program remains bug-free (if it was beforehand).
Much more agregiously you can design harmless a looking format that can run arbitrary code e.g. .doc with VBS. I have a very hard time blaming an user who falls for that even though MS puts up a scary looking popup.
Er what?? CVEs should be assigned to bugs, not bugfixes, right?
but no, in linux cve id is assigned "on a one to two week delay from when the fix has landed in a released stable kernel version."
"While many security people love to argue what is, or is not, a vulnerability, while dealing with CVEs, a CNA must follow the definition that cve.org gives us which is:
“An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.”
So with that definition in mind, the kernel CNA team members look at every bugfix that is added to the stable kernel releases and reviews it to determine if it meets this criteria."
So yes indeed, according to this, bugfixes are being examined for "instance of one or more weaknesses in a Product that can be exploited" - bugs.
Oh dear, oh dear.