‹ BackHN Continuity

Thread

Several vulnerabilities have been discovered in the Linux kernel

576 points · 408 comments · luispa

  1. embedding-shape · · focus · HN ↗
    "Several" feels a bit of an understatement, there are 1313 CVEs listed on that page!

    Wonder how many of these NSA and others been sitting on, for how long and how many are still there? I guess the silver lining with the aixplosion of CVEs is that software eventually will get more secure.

    1. SchemaLoad · · focus · HN ↗
      Something to keep in mind is the Linux project registered as an authority to create their own CVE numbers in 2024. Previously the majority of bugs would just be fixed without note unless there was a demonstration that it could be exploited.

      Now they just give almost every bug a CVE number.

    2. vdfs · · focus · HN ↗
      Any kernel bug gets a CVE even if it's not really a vulnerability or can be exploited
    3. crispr245 · · focus · HN ↗
      NSA allegedly used to have a "black budget" of around a couple dozen million dollars for software sabotaging. I wonder what percentage of those CVEs could be related to it...
      1. tclancy · · focus · HN ↗
        “A couple dozen million” feels like there should be an Imperial measurement for it à la hogshead or furlong.
    4. rurban · · focus · HN ↗
      In one the latest CCC kernel security talks, Ilya van Sprundel estimated 20.000 unfixed Linux bugs sitting around still. It's coming closer.
    5. zahlman · · focus · HN ↗
      I checked out the last (highest-numbered) one just as a quick sanity check:

      > In the Linux kernel, the following vulnerability has been resolved:

      > usb: typec: ucsi: unregister debugfs entries on teardown

      > ucsi_register() creates per-instance debugfs entries, but ucsi_unregister() keeps them around until ucsi_destroy().

      > Drivers like ucsi_glink that unregister/register the same UCSI instance across remoteproc restart then try to create an already existing debugfs directory and log:

      > debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi'

      > Unregister debugfs entries as part of ucsi_unregister(), and clear ucsi->debugfs after freeing it so repeated unregister paths remain safe.

      I'm going to need someone to explain how that could possibly become a "vulnerability".

      1. brabel · · focus · HN ↗
        All bugs in the kernel are assumed to be vulnerabilities as many others in this thread have been trying to explain.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.