Several vulnerabilities have been discovered in the Linux kernel
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
Several vulnerabilities have been discovered in the Linux kernel
Unofficial Hacker News client; not affiliated with Y Combinator.
john_strinlai · · focus · HN ↗
>“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.”
<a href="https://docs.kernel.org/process/cve.html" rel="nofollow">https://docs.kernel.org/process/cve.html
"number of cves" is a useless metric, especially when it comes to the kernel.
mbreese · · focus · HN ↗
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 · · focus · HN ↗
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.
DSMan195276 · · focus · HN ↗
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.