lwn.net Open in urlscan Pro
2600:3c03::f03c:93ff:febd:80f5  Public Scan

Form analysis
28 forms found in the DOM

Name: loginform — POST https://lwn.net/Login/

<form action="https://lwn.net/Login/" method="post" name="loginform" class="loginform">
  <label><b>User:</b> <input type="text" name="Username" value="" size="8" id="uc"></label>
  <label><b>Password:</b> <input type="password" name="Password" size="8" id="pc"></label> <input type="hidden" name="target" value="/SubscriberLink/961978/34b46ad8e2899ee5/"> <input type="submit" name="submit" value="Log in">
</form>

---

POST https://lwn.net/subscribe/

<form action="https://lwn.net/subscribe/" method="post" class="loginform">
  <input type="submit" name="submit" value="Subscribe">
</form>

---

POST https://lwn.net/Login/newaccount

<form action="https://lwn.net/Login/newaccount" method="post" class="loginform">
  <input type="submit" name="submit" value="Register">
</form>

---

POST /SubscriberLink/MakeLink

<form action="/SubscriberLink/MakeLink" method="post">
  <input type="hidden" name="articleid" value="961978">
  <input type="submit" value="Send a free link">
</form>

---

POST /Articles/962114/comment

<form action="/Articles/962114/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962124/comment

<form action="/Articles/962124/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962126/comment

<form action="/Articles/962126/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962115/comment

<form action="/Articles/962115/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962122/comment

<form action="/Articles/962122/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962127/comment

<form action="/Articles/962127/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962131/comment

<form action="/Articles/962131/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962136/comment

<form action="/Articles/962136/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962190/comment

<form action="/Articles/962190/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962195/comment

<form action="/Articles/962195/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962140/comment

<form action="/Articles/962140/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962156/comment

<form action="/Articles/962156/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962175/comment

<form action="/Articles/962175/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962177/comment

<form action="/Articles/962177/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962179/comment

<form action="/Articles/962179/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962181/comment

<form action="/Articles/962181/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962184/comment

<form action="/Articles/962184/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962204/comment

<form action="/Articles/962204/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962180/comment

<form action="/Articles/962180/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962194/comment

<form action="/Articles/962194/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962141/comment

<form action="/Articles/962141/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962182/comment

<form action="/Articles/962182/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962193/comment

<form action="/Articles/962193/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

POST /Articles/962197/comment

<form action="/Articles/962197/comment" method="post">
  <input type="submit" value="Reply to this comment">
</form>

---

Text Content

LWN
.net News from the source
 * Content
   * Weekly Edition
   * Archives
   * Search
   * Kernel
   * Security
   * Events calendar
   * Unread comments
   
   * --------------------------------------------------------------------------------
   
   * LWN FAQ
   * Write for us
 * Edition
   * Return to the Front page


User: Password:
|

|

Subscribe / Log in / New account


A TURNING POINT FOR CVE NUMBERS


[LWN SUBSCRIBER-ONLY CONTENT]


WELCOME TO LWN.NET

The following subscription-only content has been made available to you by an LWN
subscriber. Thousands of subscribers depend on LWN for the best news from the
Linux and free software communities. If you enjoy this article, please consider
accepting the trial offer on the right. Thank you for visiting LWN.net!


FREE TRIAL SUBSCRIPTION

Try LWN for free for 1 month: no payment or credit card required. Activate your
trial subscription now and see why thousands of readers subscribe to LWN.net.



By Jonathan Corbet
February 14, 2024
The Common Vulnerabilities and Exposures (CVE) system was set up in 1999 as a
way to refer unambiguously to known vulnerabilities in software. That system has
found itself under increasing strain over the years, and numerous projects have
responded by trying to assert greater control over how CVE numbers are assigned
for their code. On February 13, though, a big shoe dropped when the Linux kernel
project announced that it, too, was taking control of CVE-number assignments. As
is often the case, though, the kernel developers are taking a different approach
to vulnerabilities, with possible implications for the CVE system as a whole.

CVE numbers can be useful for anybody who is interested in whether a given
software release contains a specific vulnerability or not. Over time, though,
they have gained other uses that have degraded the value of the system overall.
Developers within software distributors, for example, have been known to file
CVE numbers in order to be able to ship important patches that would, without
such a number, not be accepted into a stable product release. Security
researchers (and their companies) like to accumulate CVE numbers as a form of
resume padding and skill signaling. CVE numbers have become a target in their
own right; following Goodhart's law, they would appear to have lost much of
their value as a result.

Specifically, in many cases, the CVE numbers resulting from these activities do
not correspond to actual vulnerabilities that users need to be worried about.
The assignment of a CVE number, though, imposes obligations on the project
responsible for the software; there may be pressure to include a fix, or
developers may have to go through the painful and uncertain process of
contesting a CVE assignment and getting it nullified. As this problem has
worsened, frustration with the CVE system has grown.

One outcome of that has been an increasing number of projects applying to become
the CVE Numbering Authority (CNA) for their code. If a CNA exists for a given
program, all CVE numbers for that program must be issued by that CNA, which can
decline to issue a number for a report that, in its judgment, does not
correspond to a real vulnerability. Thus, becoming the CNA gives projects a way
to stem the flow of bogus CVE numbers. In recent times, a number of projects,
including curl, PostgreSQL, the GNU C Library, OpenNMS, Apache, Docker, the
Document Foundation, Kubernetes, Python, and many others have set up their own
CNAs. The OpenSSF has provided a guide to becoming a CNA for other projects that
might be interested in taking that path.

Corporations, too, can become the CNA for their products. Many companies want
that control for the same reasons that free-software projects do; they grow
tired of responding to frivolous CVE-number assignments and want to put and end
to them. Of course, control over CVE assignments could be abused by a company
(or a free-software project) to try to sweep vulnerabilities under the rug.
There is an appeal process that can be followed in such cases.



THE KERNEL CNA

The kernel project has, for the most part, declined to participate in the CVE
game. Famously, the project (or, at least, some of the most influential
developers within it) has long taken the position that all bugs are potentially
security issues, so there is no point in making a fuss over the fixes that have
been identified by somebody as having security implications. Still, the kernel
has proved fertile ground for those who would pad their resumes with CVE
credits, and that grates on both developers and distributors.

The situation has now changed, and the kernel will be assigning CVE numbers for
itself. If that idea brings to mind a group of grumpy, beer-drinking kernel
developers reviewing and rejecting CVE-number requests, though, then a closer
look is warranted. The key to how this is going to be work can be found in this
patch to the kernel's documentation:



> As part of the normal stable release process, kernel changes that are
> potentially security issues are identified by the developers responsible for
> CVE number assignments and have CVE numbers automatically assigned to them.
> These assignments are published on the linux-cve-announce mailing list as
> announcements on a frequent basis.
> 
> Note, 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, but the
> possibility of exploitation is often not evident when the bug is fixed.
> Because of this, the CVE assignment team is overly cautious and assign CVE
> numbers to any bugfix that they identify. This explains the seemingly large
> number of CVEs that are issued by the Linux kernel team.

(Emphasis added). What this text is saying is that anything that looks like a
bug fix — meaning many of the changes that find their way into the stable kernel
updates — will have a CVE number assigned to it. Bear in mind that, as of
6.1.74, the 6.1 kernel (which has been out for just over one year) has had
12,639 fixes applied to it. The 4.19 kernel, as of 4.19.306, has had 27,952. Not
all of these patches will get CVE numbers, but many will. So there are going to
be a lot of CVE numbers assigned to the kernel in the coming years.

Back in 2019, LWN covered a talk by Greg Kroah-Hartman about the CVE-number
problem. From that article:



> Kroah-Hartman put up a slide showing possible "fixes" for CVE numbers. The
> first, "ignore them", is more-or-less what is happening today. The next,
> option, "burn them down", could be brought about by requesting a CVE number
> for every patch applied to the kernel.

It would appear that, nearly five years later, a form of the "burn them down"
option has been chosen. The flood of CVE numbers is going to play havoc with
policies requiring that shipped software contain fixes for all CVE numbers filed
against it — and there are plenty of policies like that out there. Nobody who
relies on backporting fixes to a non-mainline kernel will be able to keep up
with this CVE stream. Any company that is using CVE numbers to select kernel
patches is going to have to rethink its processes.

A couple of possible outcomes come to mind. One is that the CVE system will be
overwhelmed and eventually abandoned, at least with regard to the kernel. There
was not much useful signal in kernel CVE numbers before, but there will be even
less now. An alternative is that distributors will simply fall back on shipping
the stable kernel updates which, almost by definition, will contain fixes for
every known CVE number. That, for example, is the result that Kees Cook seemed
to hope for:



> I'm excited to see this taking shape! It's going to be quite the fire-hose of
> identifiers, but I think that'll more accurately represent the number of fixes
> landing in stable trees and how important it is for end users to stay current
> on a stable kernel.

It is easy to get the sense, though, that either outcome would be acceptable to
the developers in charge of mainline kernel security.

However it plays out, it is going to be interesting to watch; popcorn is
recommended. The CVE system has been under increasing stress for years, and it
hasn't always seemed like there has been much interest in fixing it. The arrival
of the kernel CNA will not provide that fix, but it may reduce the use of kernel
CVE numbers as resume padding or ways to work around corporate rules and,
perhaps, draw attention to the fact that keeping a secure kernel requires
accepting a truly large number of fixes. That might just be a step in the right
direction.


Index entries for this article KernelSecurity/CVE numbers





> Did you like this article? Please accept our trial subscription offer to be
> able to see more content like it and to participate in the discussion.



--------------------------------------------------------------------------------

(Log in to post comments)






AN ADDITIONAL QUOTE

Posted Feb 14, 2024 17:22 UTC (Wed) by corbet (editor, #1) [Link]

I hadn't seen this quote from Greg Kroah-Hartman before posting the article, but
it kind of reinforces the point:



> The "simple solution" for all of this is just to have open source projects say
> "You must update to our latest version, it fixes all known issues at this
> time".
> 
> That's what we have done in the kernel for a very long time, and I predict
> this fascination of unique identifiers somehow meaning something is going to
> go away over time as it's obviously not sustainable for anyone involved.






AN ADDITIONAL QUOTE

Posted Feb 14, 2024 18:24 UTC (Wed) by bluca (subscriber, #118303) [Link]

> "You must update to our latest version, it fixes all known issues at this
time"


"...and breaks backward compatibility in at least twice as many ways, half of
which are unknown and you'll only find in production. Good luck!"


^^^ this part was strangely missing from the quote, for some reason /s







AN ADDITIONAL QUOTE

Posted Feb 14, 2024 18:33 UTC (Wed) by pizza (subscriber, #46) [Link]

> "...and breaks backward compatibility in at least twice as many ways, half of
which are unknown and you'll only find in production. Good luck!"


Of course, you're welcome to ask for (and will receive!) a complete refund if
you're unhappy with that level of service.



















A TURNING POINT FOR CVE NUMBERS

Posted Feb 14, 2024 17:23 UTC (Wed) by dullfire (subscriber, #111432) [Link]

IIRC Kernel patches are supposed to have a "Fixes" annotation for... fixes.


Does this mean the CVE generation part can basically be fully automated. But
with possible touch ups for patches with bad commit messages.







A TURNING POINT FOR CVE NUMBERS

Posted Feb 14, 2024 18:15 UTC (Wed) by gregkh (subscriber, #8) [Link]

Yes it can, and that is what we are going to use for tracking when a problem
showed up, and when and what branch it is fixed in. CVE makes this very easy to
consume on their side as they are using JSON to handle all of it, which while
complex at times, is at least machine-parsable.






A TURNING POINT FOR CVE NUMBERS

Posted Feb 14, 2024 18:44 UTC (Wed) by bluca (subscriber, #118303) [Link]

> Famously, the project (or, at least, some of the most influential developers
within it) has long taken the position that all bugs are potentially security
issues, so there is no point in making a fuss over the fixes that have been
identified by somebody as having security implications.


It really feels like said 'influential developers' live in a world of their own
and have never actually spoken to anybody working in a commercial project
anywhere, as this is such a naive and disingenuous take that it is the most
charitable interpretation possible. The point of the CVE system should in theory
be (yes of course there's plenty of misuse and straight out abuse as noted in
the article, those are all very real problems with the system) that it allows to
quickly decide whether it's worth to drop everything on the floor and pay a
large sum of money and disrupt all your customers to go and do a kernel update,
which in most cases results in unrelated stuff breaking left and right, due to
how regressions are routinely ignored upstream, and how backward compatibility
is not really a thing that any kernel maintainer cares about, outside of the
syscalls ABI. A bug that is knowingly exploited in the wild is very, very very
different from any other random bug fixes that doesn't affect you in any way,
and it's incredibly naive to pretend they are all the same. They are very much
not for anybody running any production system.


> A couple of possible outcomes come to mind. One is that the CVE system will be
overwhelmed and eventually abandoned, at least with regard to the kernel. There
was not much useful signal in kernel CVE numbers before, but there will be even
less now. An alternative is that distributors will simply fall back on shipping
the stable kernel updates which, almost by definition, will contain fixes for
every known CVE number.


The third possible outcome is that, given shipping with known security problems
(which is synonym of unfixed CVEs, like it or not) is slowly becoming the target
of legislation in the US and the EU, companies will just stop using Linux in
their products, starting with anything to do with government contracts, given
it's essentially impossible to continuously update the kernel in production, due
to how disruptive it is and also how often new versions break backward
compatibility all over the place. Now _that_ would be a hilarious unintended
consequence.







A TURNING POINT FOR CVE NUMBERS

Posted Feb 14, 2024 19:21 UTC (Wed) by jbenc (subscriber, #40051) [Link]

I'm afraid it's going to be the last option. Greg, you're shooting all of us in
the feet. While I agree that the CVE system is broken and needs to be completely
rethought, this is not the way. It is going to backfire. I know that you think
that everybody should be using stable; I beg you to go out of your glass tower
and go see the real problems people have with the aggressive way of picking
stuff for stable. Forcing distros to take everything and the kitchen sink that
goes into stable (since this is what this is really about, either intentionally
or as an unintended consequence) is not going to make the users happy. The
quality of stable is way too low.






A TURNING POINT FOR CVE NUMBERS

Posted Feb 14, 2024 19:28 UTC (Wed) by DemiMarie (subscriber, #164188) [Link]

What would be needed to improve quality?






A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 4:09 UTC (Thu) by Darakian (subscriber, #96997) [Link]

> What would be needed to improve quality?


Funds for a team to test and curate which bugs actually have security
implications







A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 6:35 UTC (Thu) by marcH (subscriber, #57642) [Link]

> What would be needed to improve quality?


Companies using Linux "for free" should hire fewer amateurs and more
"real"software engineers who actually know how to:
- write test code,
- automate their validation
- quickly test stable branches
- bisect regressions
- file good bugs
- [optional] fix regressions themselves


You get what you paid for; if you don't pay for quality, then you don't get
quality.


[indefinite "you", not answering anyone in particular]


If stable branches are full of regressions then _prove_ it. Overwhelm them with
bug reports and... even more CVEs! The very first step is sharing _evidence_ of
the problem, otherwise nothing ever changes.


If nothing changes even after sharing evidence then maybe Linux was too cheap
and too good to be true and the wrong choice for you. Either write your own
kernel and operating system or buy a better one. Linux has been incredibly
successful but many companies still do that.


Whatever you do, before whining remember how much you paid for it.







A TURNING POINT FOR CVE NUMBERS

Posted Feb 14, 2024 19:54 UTC (Wed) by mokki (subscriber, #33200) [Link]

I'm sure the EU/US legislation will not force to fix every CVE. Instead
companies should be held responsible if their product had actual security
problems that impacted the customers.


I would hope the criteria will allow cases where companies just need to ensure
there are product is safe. That can be done by locking it down or by many other
means. But if there is a security breach as a result of a known bug that had a
fix available, but that was not provided to the customers. Then company could be
held liable.


And I think that will work transiently too. If the company in the chain did not
apply the provided upstream fix, then they themselves should be liable to their
customers.







A TURNING POINT FOR CVE NUMBERS

Posted Feb 14, 2024 21:44 UTC (Wed) by mfuzzey (subscriber, #57966) [Link]

>The point of the CVE system should in theory be that it allows to quickly
decide whether it's worth to drop everything on the floor..


But that does not and cannot work for something that is as wide scoped as the
Linux kernel.
Even assuming the CVE does refer to a real vulnerability the impact is very
usecase dependent.


A local privilege escalation on a server providing shell acounts is probably a
big deal whereas the same vulnerabiliity on an embedded device that is only
running the intended software (maybe already as root) who cares?


The problem is that CVE numbers are conceptually simple and hide a lot of the
real complexity and nuances that need to go into their sensible interpretation
and you end up with stupid policies that say "you have to fix all CVEs" (of
course that's not directly the fault of the CVE numbers themselves but the way
people try to use them).


Giving managers something they think they can understand and make decisions on
when the realities are much more complicated is generally a bad idea.


Also in my experience updates in the same stable kernel series very rarely cause
issues and those that ocasionally do slip though can be mitigated with
reasonable testing. Updating to a new kernel release does need a bit more care
and tesrting though. I think the risk of *not* updating is higher than that of
updating, providing you do test to some extent.


> companies will just stop using Linux in their products, starting with anything
to do with government contracts,


Unlikely I think. At this point is there are few viable alternatives to Linux
for vast swathes of applications. The alternatives generally either aren't open
source and involve per instance license fees (making them either insufficiently
flexible or too expensive) or lack the breadth of hardware support that Linux
enjoys (making them unusable for many, partiuclarly in embedded).







A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 0:50 UTC (Thu) by bluca (subscriber, #118303) [Link]

> But that does not and cannot work for something that is as wide scoped as the
Linux kernel.


Of course it can and does, this is just the usual kernel developers misplaced
exceptionalism and sense of grandeur. It's just some piece of software like many
others.


> Even assuming the CVE does refer to a real vulnerability the impact is very
usecase dependent.


And that's what the impact assessment and other data are used for, you are
stating the obvious. "Does this exploit apply to our product" is the standard
minimum assessment that everyone does.


> Also in my experience updates in the same stable kernel series very rarely
cause issues


They break apart all the time, as soon as they involve anything that is not
exercised on a couple dozens kernel developers laptops or desktops, and
sometimes even there, like the disk corruption bug of a couple of months ago.
New major releases are even worse, with userspace interfaces being intentionally
broken left and right.


> At this point is there are few viable alternatives to Linux for vast swathes
of applications.


I'm sure the developers of all past software that was once widespread and then
faded into obscurity thought the same at some point or another. It just needs to
stop making economic sense to use it, and that's exactly what it will happen -
back to being a toy for hobbyists. We live in a capitalist society, and all
those companies that are directly or indirectly sponsoring the vast, vast
majority of development feel no attachment nor loyalty to anything but their
share prices and profit margins.







A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 0:54 UTC (Thu) by pizza (subscriber, #46) [Link]

> New major releases are even worse, with userspace interfaces being
intentionally broken left and right.


[citation needed]


(Especically given this flies against a _very_ longstanding "don't break
userspace" rule that's kept all manner of crappy interfaces around)







A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 1:06 UTC (Thu) by bluca (subscriber, #118303) [Link]

That rule is a fantasy from a world that never existed. There is the syscall ABI
stability, and that's about it. I still remember the scramble to fix pretty much
every single udev rule in existence when the sequence of uevents was changed in
an incompatible way. Or having to throw a way a bunch of stuff and start over
when overlayfs was made incomaptible with SELinux. Or countless changes in the
netlink protocol. And so on and so forth. If you really think "don't break
userspace" really means anything, then either we have fundamentally different
ideas of what userspace actually means, or you haven't been paying much
attention.






A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 1:19 UTC (Thu) by pizza (subscriber, #46) [Link]

> That rule is a fantasy from a world that never existed.


Then why are you so grumpy about not getting something that was never promised
to begin with?


Seriously, write and/or maintain your own kernel/system if that sort of
stability matters so much to you.


("But waaah, that's too much work!" you exclaim. So if you're not willing to do
it, why do you expect others to do it for you, for free?)







A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 1:28 UTC (Thu) by bluca (subscriber, #118303) [Link]

So is it or is it not a "long standing rule"? You are the one who claimed it
was, not me






A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 8:15 UTC (Thu) by Wol (subscriber, #4433) [Link]

> So is it or is it not a "long standing rule"?


Depends what you're talking about. As far as I know udev is (developer wise)
absolutely nothing to do with the kernel.


"Do not break user space" is the rule Linus applies to the linux kernel. And
that is a big part of the reason linux is so successful. Who knows what rules
the udev guys apply to udev...


Cheers,
Wol







A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 1:08 UTC (Thu) by pizza (subscriber, #46) [Link]

> I'm sure the developers of all past software that was once widespread and then
faded into obscurity thought the same at some point or another. It just needs to
stop making economic sense to use it,


It's _vastly_ cheaper to keep using it than to replace it with something else.
By multiple orders of magnitude.


...Any replacement will necessarily need to be roughly equivalent in features
and complexity, and even if you completely discount the initial development
costs, you're going to still end up with a similar ongoing maintenance burden.











A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 6:22 UTC (Thu) by kees (subscriber, #27264) [Link]

The more I've watched the conversations around this announcement, the more I
suspect that the "middle path" outcome will be switching to using the Common
Vulnerability Scoring System (CVSS) for assessing the "applicability" of CVEs.


There are currently no plans to assign CVSS scores from cve@kernel.org, so this
may happen externally, which kind of puts things back to square one: external
entities will call out specific fixes as "important", and the cherry-picking
will continue.


Honestly, when I would do security flaw lifetime analysis, I only ever looked at
"Critical" and "High" CVEs (as rated by the Ubuntu security and kernel teams),
since there was already such a giant long tail of "Medium" and "Low". E.g. see
slides 4 & 5:
https://outflux.net/slides/2021/lss/kspp.pdf







A TURNING POINT FOR CVE NUMBERS

Posted Feb 14, 2024 19:52 UTC (Wed) by pbonzini (subscriber, #60935) [Link]

> Developers within software distributors, for example, have been known to file
CVE numbers in order to be able to ship important patches that would, without
such a number, not be accepted into a stable product release.


Any examples? Is this practice continuing?







A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 1:16 UTC (Thu) by sashal (subscriber, #81842) [Link]

How about something like CVE-2024-0562?






A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 6:04 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

I don't think this proves that having a CVE was "necessary to include the bug in
older releases". The security impact was missed back in 2022; it's been assessed
only now, and this process included filing a CVE. Apart from the affected RHEL
releases there are likely millions of devices that have the issue.


But yeah, I can see that it's a nuisance from the upstream point of view and I
agree that assigning the CVEs proactively can be an improvement.







A TURNING POINT FOR CVE NUMBERS

Posted Feb 15, 2024 7:16 UTC (Thu) by marcH (subscriber, #57642) [Link]

> CVE numbers have become a target in their own right; following Goodhart's law,
they would appear to have lost much of their value as a result.


Thank you for the Goodhart reference. Like most people I had seen many examples
of this law but I could not yet see the forest for the trees and now I'm finally
connecting all those dots.


Typical release rules like "no more than X bugs of priority Y" always felt
subjective and artificial but now I understand exactly why. Priorities are by
definition _relative_, so how could such rules make sense? If anything these
rules should look at some absolute "severity", not a relative "priority", right?
But in reality, the use of the word "priority" is a incredibly honest admission
of Goodhart's law :-)


From at least that particular "metrics" perspective, security bugs are indeed
just like other bugs.











Copyright © 2024, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds