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. SAI_Peregrinus · 1790903533 · focus · HN ↗
  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!
  1. viraptor · 1790906802 · focus · HN ↗
    > 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 · 1790907859 · focus · HN ↗
    >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 · 1790909466 · focus · HN ↗
    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.
    someonebaggy · 1790912787 · focus · HN ↗
    Why couldn't a crash caused by filesystem corruption caused by a + operator that says 1+1=3 be filed as a DoS?
    tsimionescu · 1790923340 · focus · HN ↗
    It could. But it's a CVE in the system that crashed or in the filesystem, not in the calculator web service that we were discussing. If a filesystem decides to use a bad online calculator for its internal logic, that's a vulnerability on the filesystem, not the calculator.
    asdfaoeu · 1790931169 · focus · HN ↗
    We aren't talking about a calculator web service though we are talking about the Linux kernel and if there's a bug in the kernel that could conceivably cause a crash in an otherwise correctly written application then that would be a CVE in the kernel.
    asdfaoeu · 1790910551 · focus · HN ↗
    It's not hard to imagine an application for which 1+1 = 3 leads to security issue.
    viraptor · 1790929005 · focus · HN ↗
    <a href="https://news.ycombinator.com/item?id=49929389">https://news.ycombinator.com/item?id=49929389
    nikanj · 1790919039 · focus · HN ↗
    That’s not what Mitre thinks though, they are very happy to host a 9.8 severity CVE for 1+1=3. They’ll probably publish one for 1-1=0 too, if you preface with ”The users of mathematics might not be prepared for zero values”
    eastbound · 1790920444 · focus · HN ↗
    This is why you need a library for additions. At least CVEs can be tracked appropriately, rather than the developer rolling out their NIH solution.
    josephg · 1790921433 · focus · HN ↗
    There’s probably an npm library for that. Not all heroes wear capes.
    viraptor · 1790929285 · focus · HN ↗
    You're memeing on bad cve handling, but that's so far outside of what the real issues are, it just doesn't make sense. How about telling people about what the real problems with vulnerability classification are, rather than mitre=bad?
    nikanj · 1790929960 · focus · HN ↗
    The real problem with vulnerability classification is that mitre=bad
    <a href="https://daniel.haxx.se/blog/2026/06/24/a-cve-dispute/" rel="nofollow">https://daniel.haxx.se/blog/2026/06/24/a-cve-dispute/
    literalAardvark · 1790939605 · focus · HN ↗
    Not really. cURL developers just have NIH syndrome.
    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?
    woodruffw · 1790943741 · focus · HN ↗
    From experience: many companies have a “risk management system” that involves nagging OSS projects to do free work for them, even when the advisory is manifestly nonsense or has no impact in context. Many teams have a “green dot” mindset, and CVE directly encourages that behavior by stapling CVSS scores to identifiers.
    kbolino · 1790953849 · focus · HN ↗
    > cURL developers just have NIH syndrome.
    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.
    dzhiurgis · 1791153234 · focus · HN ↗
    > cURL is one of the most load-bearing pieces of software in existence.
    Is it really, or it's trivially replaceable by wget?
    kbolino · 1791159403 · focus · HN ↗
    You may never have dug that deep into their respective documentation, and you may never have even heard of libcurl, but their superficial overlap in ability to download a single file from an HTTP server does not make them "trivially replaceable" with each other (in either direction).
    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.
    viraptor · 1790942599 · focus · HN ↗
    Tell us about a system for managing vulnerability database that works across enterprise, private and open source, is staffed enough to research both impact and disputes, is funded enough to work for decades, isn't partisan to any industry interests, can classify vulnerabilities in a non ambiguous way, can handle public submissions at any volume in a timely manner...
    and one that will never make decisions that is incorrect or disliked by any party.
    nikanj · 1791025887 · focus · HN ↗
    I'll get back to this conversation after Mitre publicly says "We handled CVE-123 wrong". Everybody gets one wrong sometimes, but what happens after that
    viraptor · 1791026715 · focus · HN ↗
    The linked article ends with mitre confirming the outcome is what the curl project wanted. The dispute process is there exactly because some cases are ambiguous, or hard, or people involved are annoying. Whenever there are two sides with a dispute, one will likely claim Mitre handled something wrong, by definition of a dispute. They get to make decisions. So what exactly do you want from this case? Perfect decision making every time? They're handling thousands of cases and there will always be mistakes at that scale - some will be subjective things that people will disagree about forever.
    [deleted] · 1790919886 · focus · HN ↗
    [deleted]
    goodmythical · 1790949188 · focus · HN ↗
    >hash of supplied password does not match hash of stored password, access denied
    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.
    viraptor · 1791019080 · focus · HN ↗
    <a href="https://news.ycombinator.com/item?id=49929389">https://news.ycombinator.com/item?id=49929389
    I'm using specific words and it's been explained and linked twice already. Come on!

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.