5 comments

  • 1vuio0pswjnm74 hours ago
    <a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20251210012827if_&#x2F;http:&#x2F;&#x2F;www.kroah.com&#x2F;log&#x2F;blog&#x2F;2025&#x2F;12&#x2F;08&#x2F;linux-cves-more-than-you-ever-wanted-to-know&#x2F;" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20251210012827if_&#x2F;http:&#x2F;&#x2F;www.kro...</a>
  • paulryanrogers8 hours ago
    Looking forward to posts links in the series. This seems like a bit of a tease.
    • dredmorbius8 hours ago
      2nd &#x27;graph of TFA links five talks on the topic all within the past two years.
      • paulryanrogers5 hours ago
        Perhaps I misunderstand, but aren&#x27;t those far above the &quot;So here’s a series of posts&quot; and its bullet list?
  • loph8 hours ago
    [flagged]
    • tomhow8 hours ago
      <i>Please don&#x27;t complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They&#x27;re too common to be interesting.</i><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;newsguidelines.html">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;newsguidelines.html</a>
    • landr0id8 hours ago
      I&#x27;m surprised Firefox didn&#x27;t warn me when I went to the page. Hostile teleco&#x2F;MITM waiting for HTTP traffic are a real-world way that nation states deliver exploits.
      • vpShane7 hours ago
        It did for Librewolf -- what I moved to from Firefox. Self-Signed certs I&#x27;m down with, http I&#x27;m not, and never will be for any reason. Plain-text data transmissions have no acceptable reasoning.
        • schmuckonwheels7 hours ago
          You do realize self-signed certs are useless, could have been tampered with, and could have just as easily been created by a malicious actor?<p>There&#x27;s a reason most default self signed certs are called &quot;snake oil&quot;.
          • gldrk6 hours ago
            You can pre-share the certificate out of band, or set up your browser to TOFU like SSH does. Then they are not useless and may be superior to PKI for certain threat models.
      • gldrk6 hours ago
        PKI is basically powerless against nation states executing a targeted MITM attack. It does prevent them from passively snooping everything.
      • vhcr6 hours ago
        You can enable it in the settings.
    • actionfromafar8 hours ago
      Posted on December 8, 2025 | Greg K-H<p>It’s been almost 2 full years since Linux became a CNA⁰ (Certificate Numbering Authority) which meant that we (i.e. the kernel.org community) are now responsible for issuing all CVEs for the Linux kernel. During this time, we’ve become one of the largest creators of CVEs by quantity, going from nothing to number 3 in 2024 to number 1 in 2025. Naturally, this has caused some questions about how we are both doing all of this work, and how people can keep track of it.<p>I’ve given a number of talks over the past years about this, starting with the Open Source security podcast right after we became¹ a CNA and then the Kernel Recipes 2024 talk, “CVEs are alive, but do not panic”² and then a talk³ at OSS Hong Kong 2024 about the same topic with updated numbers and later a talk at OSS Japan⁴ 2024 with more info about the same topic and finally for 2024 a talk with more detail⁵ that I can’t find the online version.<p>In 2025 I did lots of work on the CRA⁶ so most of my speaking⁷ over this year has been about that topic , but the CVE assignment work continued on, evolving to meet many of the issues we had in our first year of being a CNA. As that work is not part of the Linux kernel source directly, it’s not all that visable to the normal development process, except for the constant feed on the linux-cve-announce mailing list⁸ I figured it was time to write down how this is all now working, as well a bunch of background information about how Linux is developed that is relevant for how we do CVE reporting (i.e. almost all non-open-source-groups don’t seem to know how to grasp our versioning scheme.)<p>There is a in-kernel document⁹ that describes how CVEs can be asked for from the kernel community, as well as a basic summary of how CVEs are automatically asigned. But as we are an open community, it’s good to go into more detail as to how all of us do this work, explaining how our tools have evolved over time and how they work, why some things are the way they are for our releases, as well as document a way that people can track CVE assignments on their own in a format that is, in my opinion, much simpler than attempting to rely on the CVE json format (and don’t get me started on NVD…)<p>So here’s a series of posts going into all of this, hopefully providing more information than you ever wanted to know, which might be useful for other open source projects as they start to run into many of the same issues we have already dealt with (i.e. how to handle reports at scale):<p><pre><code> Linux kernel versions, how the Linux kernel releases are¹⁰ numbered.</code></pre> (contents served over SSL, by virtue of YC)<p>0: <a href="http:&#x2F;&#x2F;www.kroah.com&#x2F;log&#x2F;blog&#x2F;2024&#x2F;02&#x2F;13&#x2F;linux-is-a-cna&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.kroah.com&#x2F;log&#x2F;blog&#x2F;2024&#x2F;02&#x2F;13&#x2F;linux-is-a-cna&#x2F;</a><p>1: <a href="https:&#x2F;&#x2F;opensourcesecurity.io&#x2F;2024&#x2F;02&#x2F;25&#x2F;episode-417-linux-kernel-security-with-greg-k-h&#x2F;" rel="nofollow">https:&#x2F;&#x2F;opensourcesecurity.io&#x2F;2024&#x2F;02&#x2F;25&#x2F;episode-417-linux-k...</a><p>2: <a href="https:&#x2F;&#x2F;kernel-recipes.org&#x2F;en&#x2F;2024&#x2F;cves-are-alive-but-no-not-panic&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kernel-recipes.org&#x2F;en&#x2F;2024&#x2F;cves-are-alive-but-no-not...</a><p>3: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=at-uDXbX-18" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=at-uDXbX-18</a><p>4: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=KumwRn1BA6s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=KumwRn1BA6s</a><p>5: <a href="https:&#x2F;&#x2F;ossmw2024.sched.com&#x2F;event&#x2F;1sLVt&#x2F;welcome-keynote-50-cves-a-week-how-the-linux-kernel-project-went-from-ignoring-cves-to-embracing-them-greg-kroah-hartman-fellow-the-linux-foundation" rel="nofollow">https:&#x2F;&#x2F;ossmw2024.sched.com&#x2F;event&#x2F;1sLVt&#x2F;welcome-keynote-50-c...</a><p>6: <a href="https:&#x2F;&#x2F;digital-strategy.ec.europa.eu&#x2F;en&#x2F;policies&#x2F;cyber-resilience-act" rel="nofollow">https:&#x2F;&#x2F;digital-strategy.ec.europa.eu&#x2F;en&#x2F;policies&#x2F;cyber-resi...</a><p>7: <a href="https:&#x2F;&#x2F;kernel-recipes.org&#x2F;en&#x2F;2025&#x2F;schedule&#x2F;the-cra-and-what-it-means-for-us&#x2F;" rel="nofollow">https:&#x2F;&#x2F;kernel-recipes.org&#x2F;en&#x2F;2025&#x2F;schedule&#x2F;the-cra-and-what...</a><p>8: <a href="https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-cve-announce&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lore.kernel.org&#x2F;linux-cve-announce&#x2F;</a><p>9: <a href="https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;html&#x2F;latest&#x2F;process&#x2F;cve.html" rel="nofollow">https:&#x2F;&#x2F;www.kernel.org&#x2F;doc&#x2F;html&#x2F;latest&#x2F;process&#x2F;cve.html</a><p>10: <a href="http:&#x2F;&#x2F;www.kroah.com&#x2F;log&#x2F;blog&#x2F;2025&#x2F;12&#x2F;09&#x2F;linux-kernel-version-numbers&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.kroah.com&#x2F;log&#x2F;blog&#x2F;2025&#x2F;12&#x2F;09&#x2F;linux-kernel-versio...</a>
  • 1970-01-018 hours ago
    [flagged]
    • kvemkon8 hours ago
      But how do you know, that if kroah.com would use Let&#x27;s Encrypt it would belong to Greg K-H? What if his true WEB-site would be e.g. greg-k-h.com?
      • a99c43f2d5655048 hours ago
        Right. Also, when it comes to the other aspects of TLS, such as preventing middlemen from making sense of what information flows between you and the server, what exactly is the threat in this case? I mean, it&#x27;s a public blog post, which you only ask to read and so you are served.
        • vpShane7 hours ago
          It&#x27;s not about threat, it&#x27;s about privacy. I understand your statements but &#x27;what is the threat in this case&#x27; to answer that: I don&#x27;t want to know, I&#x27;ve moved on from those worries. Always encrypt.
          • vhcr6 hours ago
            What privacy? Whoever is watching your traffic can see you accessed their website with HTTPS, they can guess with high accuracy which article you are reading based on the response size.
    • schmuckonwheels8 hours ago
      Objectively better than serving 12MB of JavaScript slop, trackers, and &quot;analytics&quot; over HTTPS so you can share a recipe for flan.<p>Greg K-H has more credibility than 99% of posters here.<p>He&#x27;s literally the #2 guy in Linuxworld (behind Linus). What have you done?
      • 1970-01-017 hours ago
        You enumerated the security risks of clear text transmission over the Internet and everything came up green because the blogger works on Linux?
        • MobiusHorizons3 hours ago
          Please don&#x27;t get me wrong. I&#x27;m glad the world has mostly transitioned over to HTTPS, but what are you actually concerned about with reading a blog post over HTTP? If you had to log in or post form data, or hosted binaries or something I would get it. But what is wrong with reading an article in the clear? And how would SSL prevent that?
        • schmuckonwheels7 hours ago
          If you are too afraid to click a cleartext HTTP link then don&#x27;t; it&#x27;s not for you. Just spare the rest of us the melodrama.<p>While you are at it, better not ever update Debian or any number of other OSes because their updates are served over plain HTTP.
          • 1970-01-017 hours ago
            You <i>almost</i> had a great point here. If he began every blog rant with BEGIN PGP SIGNED MESSAGE and included a digital key somewhere secure, somewhere that I could go and verify, just Debian does with updates, I maybe could tolerate the cleartext. But he <i>clearly</i> didn&#x27;t (pun alert!)
      • vpShane7 hours ago
        I enjoy this person&#x27;s writings, and contributions. I am Linux&#x27;s biggest fan and research cyber security daily.<p>I would prefer https.
        • schmuckonwheels7 hours ago
          I prefer a nice cappuccino, but sometimes all that&#x27;s available is plain black coffee from the shared pot in the canteen (which someone could have tampered with).<p>But we drink it anyway (at risk) because it&#x27;s free.
  • throw3290848 hours ago
    This blog post, brought to you by the man who wants to burn down the CVE system <a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;1049140&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;1049140&#x2F;</a>
    • accelbred3 hours ago
      I, this last week, had to spend hours dealing with a fake CVE that was opened 2 years ago on an open source dependency of our project for a bug that amounts to &quot;if you have RCE, you can construct a malicious java datatype and call this function on it to trigger a stack overflow&quot;. The github thread on the lib is full of the maintainers having to deal with hundreds of people asking them for updates on an obviously fake CVE. Yet the CVE is still up and has not been deleted. And I now get a request from a customer about fixing this vuln in our code their CVE scanner found.<p>The CVE system is broken and its death would be a good riddance.
    • TheDong4 hours ago
      One of the many people who know the CVE system is elaborately broken in many ways.<p>Please, tell me what issues you have with how the kernel does CVEs.
      • raesene91 hour ago
        Not op but if you are looking for information on why sone people arent keen on the kernels approach to CVE management <a href="https:&#x2F;&#x2F;jericho.blog&#x2F;2024&#x2F;02&#x2F;26&#x2F;the-linux-cna-red-flags-since-2022&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jericho.blog&#x2F;2024&#x2F;02&#x2F;26&#x2F;the-linux-cna-red-flags-sinc...</a> might be of interest
    • DeepYogurt5 hours ago
      To be fair the CVE system can&#x27;t even encode a version string
      • spockz24 minutes ago
        Not sure whether this is a limitation of the scanning tooling or of the CVE format itself, it also cannot express sub packages. So if some Jackson-very-specific-module has a CVE the whole of Jackson gets marked as impacted. Same with netty.