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. Gigachad · 1790907992 · focus · HN ↗
    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"
    autoexec · 1790917847 · focus · HN ↗
    "Update everything immediately just in case" is a lot less attractive when you see more downtime from updates breaking things than you do from hackers. Windows updates are an endless source of pain, but now every program seems to demand to be updated practically daily. Even things that you shouldn't have to think about like keyboards, mice, and printers beg to be updated all the time.
    Gigachad · 1790923617 · focus · HN ↗
    Downtime is annoying but workable. You can't unleak customer data after your system gets hacked.
    1718627440 · 1790925019 · focus · HN ↗
    There is no reason, why a newer version has less bugs, than an older version. Both are essentially an unknown number. The only thing you know, is that you likely know a higher percentage of bugs for the older than for the newer version.
    Gigachad · 1790926060 · focus · HN ↗
    It certainly has less known bugs. And when you have to make a statement to the media, “we were hacked by an undiscovered 0 day exploit” sounds a lot better than “we were hacked by a known exploit because we didn’t update”
    1718627440 · 1790928169 · focus · HN ↗
    If you do know about it, you can also just mitigate that.
    seb1204 · 1790936980 · focus · HN ↗
    I do this this is theoretical, especially with recent spread ups.
    fwip · 1790960932 · focus · HN ↗
    > It certainly has less known bugs.
    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.
    izacus · 1790939214 · focus · HN ↗
    Yeah, the fact that security forces you to update has been used with great effect by product managers and feature engineers to shove their changes down everyone's throat and quickly drop support for previous versions. Neat for them.
    cesarb · 1790967785 · focus · HN ↗
    > I've watched it shift from "Only update if we can prove we are impacted" to "Update everything immediately just in case".
    > [...] 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.
  2. 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.
  3. someonebaggy · 1790912826 · focus · HN ↗
    They chose to do it this way, in. part, because CVEs were already like that, and too many people were pretending they weren't.
  4. weinzierl · 1790922829 · focus · HN ↗
    Counterproductive for whom? The stance of the kernel developers is that whether a bug is a vulnerability or not depends on intended use. They say, we do not dictate use, therefore this decision is out of scope for us. This makes kernel development more focussed and productive.
    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.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.