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. rerdavies · 1790903492 · focus · HN ↗
  With particular emphasis on "almost any bug might be exploitable".
  1. SoftTalker · 1790905323 · focus · HN ↗
    Even a bug-free program might be exploitable.
    catlifeonmars · 1790905605 · focus · HN ↗
    That sounds like a bug
    SoftTalker · 1790906390 · focus · HN ↗
    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.
    odo1242 · 1790906687 · focus · HN ↗
    At that point you're exploiting the user, who is not a bug-free program
    rerdavies · 1790916766 · focus · HN ↗
    Remove user and press any key to continue.
    :-P
    whiskey-one · 1790945189 · focus · HN ↗
    Indeed, the user is the hardest part of the program to secure.
    catlifeonmars · 1790909590 · focus · HN ↗
    But if you squint, it might be a bug in the system to allow access to that program.
    bigstrat2003 · 1790913320 · focus · HN ↗
    That's also not exploiting the program, it's exploiting the user.
    PaulDavisThe1st · 1790916093 · focus · HN ↗
    Alternatively, consider any program which loads dynamic shared libraries (called "plugins" in many contexts). The program itself might be bug free; any plugin that is loaded will run (typically) with the full priviledges and access of the program (and thus likely the user).
    The user may have no idea that the plugin is malicious; the program remains bug-free (if it was beforehand).
    nananana9 · 1790953487 · focus · HN ↗
    At least with plugins most people have a general notion that they run some sort of code as they provide some new functionality.
    Much more agregiously you can design harmless a looking format that can run arbitrary code e.g. .doc with VBS. I have a very hard time blaming an user who falls for that even though MS puts up a scary looking popup.
    GoblinSlayer · 1790965346 · focus · HN ↗
    Nope, sudo is safer, the alternative is running everything as root.
    PowerElectronix · 1790928167 · focus · HN ↗
    Totally a feature
2. 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!
  2. jeroenhd · 1790922696 · focus · HN ↗
    Loads of bugs aren't CVE-worthy. If you tell the computer to make a light green but it makes the light red, that's a bug but no DoS or other CVE-worthy bug.
    However, the Linux kernel is supposed to run any userland program without crashing, so anything that crashes the kernel is a local DoS and there are a lot of them. It's also supposed to shield processes from each other and maintain privilege levels correctly, so many incorrect memory leaks are also CVE worthy. Whether a CVE applies depends on the people and programs using the kernel, and the kernel team can't read your code to tell you if it applies or not.
    People reading CVEs wrong ("it's got a high number so we must patch within a day") must be going crazy over this, but the point of CVEs is to let you make judgement calls, not to be a cool statistic about how secure something is.
    Most CVEs are irrelevant to most people, that's always been the case.
    somat · 1790928516 · focus · HN ↗
    "why did the ship crash?"
    Unpatched bug, wrong color lights.
    Yes, it is a bit of a stretch, I desperately hope programmable navigation lights are not a thing. And I also don't think every bug needs a CVE. But in the correct context nearly any bug could be critical.
    seanhunter · 1790929387 · focus · HN ↗
    Computer Weekly in the UK did some pioneering journalism into a helicopter crash[1] that had initially been blamed on the two pilots but seems very likely to have been caused by a failure of a computer system that was controlling the fuelling of the engines. Iirc this system seems to have crashed causing engine failure of both engines in heavy fog, bringing the helicopter down with a loss of everyone on board, however for reasons somewhat unclear, the MOD wanted to cover the failure up by blaming the pilots.
    Now this was a windows system[2] rather than linux but the point remains - if there was an external vulnerability in a crucial control system and this system was part of a network (eg to connect telemetry) then any exploit of that system could result in loss of life.
    [1] <a href="https://www.computerweekly.com/news/1280091718/Chinook-computer-was-positively-dangerous-say-newly-disclosed-MoD-documents" rel="nofollow">https://www.computerweekly.com/news/1280091718/Chinook-compu...
    After an assessment of the Fadec software the Superintendent of Engineering Systems said that the density of deficiencies was so high that the software was unintelligible.
    [2] Which, why? Why build the fuel controller for a helicopter engine on windows?
    rjsw · 1790932267 · focus · HN ↗
    Are you sure that the Chinook used Windows? I have not read this elsewhere.
    There have been documented problems with Windows for Warships.
    seanhunter · 1790939341 · focus · HN ↗
    My memory is ancient so may be flawed but that is what I remember. This seems to be a full chronology of the incident if you’re interested <a href="https://www.computerweekly.com/news/1280096804/Chronology-The-Chinook" rel="nofollow">https://www.computerweekly.com/news/1280096804/Chronology-Th...
    sas224dbm · 1790943160 · focus · HN ↗
    A windows system controlling the refuelling ? Worked in aviation software for a while and the certification for flight control (or similar) systems is subject to rigorous path testing/inspections/approvals etc DO-178C (level A or B likely). Not sure if any windows OS is certified to level A?? Typically certifiable RTOS'es are procured for those purposes
    jeroenhd · 1790940953 · focus · HN ↗
    That's still not cause for a CVE, even if it's a bad bug.
    MyMemoryfails · 1790928612 · focus · HN ↗
    Unless that computer happens be on traffic lights. Will this become CVE? Human life would be at risk.
    GTP · 1790938769 · focus · HN ↗
    This is actually the point of the parent comment: you have to read the CVE and see for yourself if it impacts your specific system or not.
    sigmoid10 · 1790939584 · focus · HN ↗
    If only the user can tell whether something is potentially dangerous, then either every bug or none of them should get a CVE. There are countless systems out there that are commonly used in ways beyond what even the developer intended, how should a third party authority like the CNA be able to discern this?
    TeMPOraL · 1790942743 · focus · HN ↗
    They can't. Which is why security discussions are such a hot mess.
    The vendors fixing them arguably prioritize these reports right. Most of the CVEs, even severe ones, are irrelevant in practice, and as parents note, are more like regular bugs with security flavor in reporting. The CVE label instead of regular bug tracking number makes them seem important.
    Linux Kernel may be one of the few legitimate exceptions, indeed, due to the position in which it sits in the software stack. Also LLMs make previously unexploitable-in-practice vulnerabilities exploitable (by making targeted / personalized attack cheap enough to give them positive ROI), which complicates things.
    openasocket · 1790948725 · focus · HN ↗
    I think you have to make a distinction between bugs and actual vulnerabilities. Therac-25 killed people, but I wouldn’t consider anything about it to be a security vulnerability. In my mind, the distinction between a bug and a vulnerability is that a bug is triggered during “normal” operations and can do anything. Whereas a vulnerability requires an adversary to “trigger” the vulnerability, and can do this to achieve some cognizable malicious goal. There’s probably some overlap on the edges; whether an issue in a library is a bug or a vulnerability may depend on how it is used, for example.
    But I think the most important thing to keep in mind is that a bug isn’t necessarily less serious or less important than a vulnerability. A serious bug should be patched just as urgently as a serious vulnerability.
    funcDropShadow · 1790934279 · focus · HN ↗
    Unless it is the led showing the status of a camera.
    literalAardvark · 1790939170 · focus · HN ↗
    Yeah in that case it's a feature and management can proudly proclaim "we own the glass"
    [deleted] · 1790943906 · focus · HN ↗
    [deleted]
    Sesse__ · 1790940574 · focus · HN ↗
    > but the point of CVEs is to let you make judgement calls
    Realistically, most admins cannot make judgment calls about 1000+ CVEs for a kernel release.
    jurgenburgen · 1790943466 · focus · HN ↗
    Usually the security team mandates a zero CVE policy on all deployments and the organization complies.
    lstodd · 1790950612 · focus · HN ↗
    we in security teams can only dream of such incompetent management
    zero CVE policy = halt on business development.
    dormento · 1790944226 · focus · HN ↗
    And not only that, remember the hn crowd is not at all representative of the average.
    Even more realistically, many admins do not have the background to be able to reason (by themselves) about the actual risk of most CVEs, so just going along with specialized media coverage is often a sound strategy.
    wang_li · 1790957857 · focus · HN ↗
    >And not only that, remember the hn crowd is not at all representative of the average.
    We should keep our hopes up, someday we may get there.
  3. spragl · 1790922802 · focus · HN ↗
    [dead]
3. [deleted] · 1790906915 · focus · HN ↗
  [deleted]
4. 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.
5. st_goliath · 1790926641 · focus · HN ↗
  > _any_ bugfix is assigned a cve
  Any patch that is back ported to a stable kernel, indiscriminately. And they have also started assigning CVSS scores with the same kind of malicious compliance.
  Take for example, this patch in the device mapper RAID code:
  <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47f1441b281decde6954a2fa82b4131637d685ac" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  After back porting to stable, it got assigned CVE-2026-89558 (which is in this list), and a CVSS score of 9.8:
  <a href="https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2026/CVE-2026-89558.cvss" rel="nofollow">https://git.kernel.org/pub/scm/linux/security/vulns.git/tree...
  Reasoning behind it being that theoretically, a RAID could be accessible over the network via NFS, iSCSI, etc... so if it gets corrupted, the buggy code path in the recovery (CVE-2026-89558) is effectively triggered over the network.
  1. marcosdumay · 1790959556 · focus · HN ↗
    There's nothing malicious about the CVE. It lets people use it to index issues, like it was supposed to, and stops dumb people from using it as an indicator of work done or vulnerability level, things that it was never useful for.
    IshKebab · 1790965931 · focus · HN ↗
    Uhm I'm pretty sure a severity score is supposed to be a score of severity.
6. aiXis · 1790928461 · focus · HN ↗
  [dead]
7. chrisjj · 1790931171 · focus · HN ↗
  > Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.
  Er what?? CVEs should be assigned to bugs, not bugfixes, right?
  1. john_strinlai · 1790950124 · focus · HN ↗
    the whole process is talked about here (and the companion posts): <a href="http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/" rel="nofollow">http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignmen...
    but no, in linux cve id is assigned "on a one to two week delay from when the fix has landed in a released stable kernel version."
    chrisjj · 1790955667 · focus · HN ↗
    Thanks.
    "While many security people love to argue what is, or is not, a vulnerability, while dealing with CVEs, a CNA must follow the definition that cve.org gives us which is:
    “An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.”
    So with that definition in mind, the kernel CNA team members look at every bugfix that is added to the stable kernel releases and reviews it to determine if it meets this criteria."
    So yes indeed, according to this, bugfixes are being examined for "instance of one or more weaknesses in a Product that can be exploited" - bugs.
    Oh dear, oh dear.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.