Thread

Several vulnerabilities have been discovered in the Linux kernel

576 points · 408 comments · luispa

john_strinlai · 1790902914 · focus · HN ↗
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.”
<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.
1. mbreese · 1790907391 · focus · HN ↗
  > 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.
  1. socializer · 1790908045 · focus · HN ↗
    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.
    vlovich123 · 1790910200 · focus · HN ↗
    The counterpoint is that by putting CVEs on bugs that are more easily exploitable provides a roadmap for attackers. Of course, in the current LLM age that's probably a moot point, but that could be the reason for this.
    seb1204 · 1790936893 · focus · HN ↗
    security by obscurity?
    cannonpalms · 1790944936 · focus · HN ↗
    Obscurity is a valuable layer of defense-in-depth
    asdfaoeu · 1790910417 · focus · HN ↗
    Let's say they do and only 5% are "security issues" you still need to update either way.
    serbuvlad · 1790924701 · focus · HN ↗
    I don't think that Linus is dismissive of security, it is that he is very much a proponent of always rolling to the latest stable release.
    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)
    LtWorf · 1790928921 · focus · HN ↗
    > Linux only ever wanted to promise support for the latest release and even Linux LTS is a concession.
    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.
    serbuvlad · 1790944960 · focus · HN ↗
    I have had way more issues provoked on RHEL-compatibles by RHEL's Frankenstein backporty kernel than I ever have on Arch or Nix by the latest stable kernel.
    Linux LTS is much more about proprietary drivers targeting a stable internal kernel API/ABI than about anything else.
    LtWorf · 1790950092 · focus · HN ↗
    I mean… good for you. How does that help me when my software crashes because they changed some API?
    mwwaters · 1790952898 · focus · HN ↗
    Which userspace API was changed?
    Internal Kernel API changes all the time which can break proprietary drivers. But userspace API has a far higher guarantee.
    LtWorf · 1790957529 · focus · HN ↗
    setsockopt changing behaviour and crashing processes.
    doublepg23 · 1790952988 · focus · HN ↗
    What user space APIs have they been routinely breaking?
    throwaway7356 · 1790955085 · focus · HN ↗
    The ones to manage IP filtering rules for example. Those APIs are even security-critical.
    LtWorf · 1790955848 · focus · HN ↗
    setsockopt that do nothing easily go to crashing the process in later versions…
    DSMan195276 · 1790952625 · focus · HN ↗
    > 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.
    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.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.