Linux CVEs, more than you ever wanted to know –

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.

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.

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.)

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…)

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):