| ▲ | john_strinlai 2 hours ago |
| note that _any_ bugfix is assigned a cve, which makes for big numbers. >“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. |
|
| ▲ | SAI_Peregrinus 2 hours ago | parent | next [-] |
| Tautologically every bug can legitimately be assigned a CVE, since every bug prevents some feature from working as intended. It's therefore a denial of service, which by the definition of the CVE system using CVSS means every bug is at least a 1/Low level vulnerability to CVSS v4.0. 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! |
| |
| ▲ | viraptor an hour ago | parent [-] | | > It's therefore a denial of service 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. | | |
| ▲ | Gigachad 36 minutes ago | parent [-] | | >but it's not a possible DoS situation 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. | | |
| ▲ | viraptor 9 minutes ago | parent [-] | | That's an issue in the other code, not in the addition service. It would be lumped together if it was an addition function close to the other code. But I wrote service there on purpose. |
|
|
|
|
| ▲ | mbreese 44 minutes ago | parent | prev | next [-] |
| > note that _any_ bugfix is assigned a cve 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. |
| |
| ▲ | socializer 33 minutes ago | parent | next [-] | | It's not very interesting. Linus, and by extension the Linux kernel, long had a dismissive attitude toward security research. This is basically a childish swing from one extreme (nothing gets a CVE) to another (everything gets a CVE). 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. | |
| ▲ | Gigachad 34 minutes ago | parent | prev [-] | | Depends on the end consumers stance on security. I've watched it shift from "Only update if we can prove we are impacted" to "Update everything immediately just in case". 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" |
|
|
| ▲ | theteapot an hour ago | parent | prev | next [-] |
| I've been following these announcements for a few years. This is the most CVEs I've seen in one by a wide margin, although there have been some big sets coming through for things like chromium, openssl. I agree it's mostly meaningless without context. So what's the context? Who/what found all these bugs? |
|
| ▲ | rerdavies 2 hours ago | parent | prev [-] |
| With particular emphasis on "almost any bug might be exploitable". |
| |
| ▲ | SoftTalker an hour ago | parent [-] | | Even a bug-free program might be exploitable. | | |
| ▲ | catlifeonmars an hour ago | parent [-] | | That sounds like a bug | | |
| ▲ | SoftTalker an hour ago | parent [-] | | There are programs like sudo whose entire reason for existing is to enable privilege escalation. If you can find a way to make a user "sudo" something, that's an exploit, but it's not a bug in the program. | | |
|
|
|
