Did a quick *rough* check:

* 65 #Linux #kernel CVE announcements from Greg so far

* 55 of those refer to a mainline commit

* 10 of those were marked for backporting to stable/longterm

And that's why Greg backports a lot of #LinuxKernel mainline commits to stable/longterm that are *not* tagged for backporting -- and why "only backport changes mainline developers[1] tagged for backporting" is a bad idea.

[1] reminder, such tagging is optional, as participation in stable/longterm is optional

@joshbressers No idea, ask NVD. The original json record we upload to cve.org does not have that field at all: https://cveawg.mitre.org/api/cve/CVE-2024-26599

@joshbressers I thought that was the correct field for that based on something, I can't remember what. You mean `assignerOrgId`, right? I don't see a field marked `sourceIdentifier` in our json output. Or are you talking about a different field?

The #Linux kernel developers are now issuing their own, more accurate Common Vulnerabilities and Exposures #security bulletins. https://opensourcewatch.beehiiv.com/p/linux-gets-cve-security-business by @sjvn

The Linux kernel developers are now in charge of its Common Vulnerabilities and Exposures (CVE) security problems.

Computer folks, remember the precedence of operators! Consult this handy list if in doubt:

() [] -> .
! ~ ++ --
* / %
+ -
<< >>
< <= > >=
== != &=
=== &&& |||
?: ??= ( ^..^)ﾉ
(╯°□°)╯︵ ┻━┻

v6.5 fixed almost twice as many "high" CVEs (19) than the second most prolific release, v6.6 (11), with v6.4 & v5.17 tied for 3rd place (9). It seems like the rate of fixing is picking up.

Ignoring the first git release (v2.6.12), the "high" flaw introduction counts are relatively even. Highest (i.e. most well tested/researched) releases have been v3.8 (9), v3.18 & v2.6.20 tied (8), and v5.9 & v4.1 tied (6).

But certainly more flaws are in all releases -- they just haven't been found yet.

Last time I did a Linux kernel security flaw lifetime analysis was back in 2021. It showed the average time between flaw introduction and fix was 5.5 years for 108 "high priority" CVEs:
https://outflux.net/slides/2021/lss/kspp.pdf

I refreshed my dataset today and was surprised to see that now with 103 more CVEs, it's still holding at 5.5 years. This actually means Linux is getting faster at finding issues, but the (diminishing) technical debt of the past is still dragging down the average.

@alexmurray I have a whole talk about this, with pretty slides and everything! https://kernel-recipes.org/en/2023/demystifying-the-linux-kernel-security-process/

@alexmurray Nope, sorry, we can't do that for obvious reasons.

@alexmurray That's going to be more complex, as you say, so we will come up with something when it happens.

The current scripts I wrote want a one-to-one mapping, but we will fix this in the future. Let's get the simple ones working first please. The mapping of commit to version numbers is complex enough to get right, we are still hashing it out as to the proper way to encode it all correctly.

See the huge comment block in the tool `bippy` for the issues involved in just single commit tracking: https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/scripts/bippy#n255

@Cirio Yes, that presentation was last year, things change, and my presentation this year at Kernel Recipes will go into what has changed and why.

@soaproot Then they will have a weekly "update our kernels" TODO item, much like we have been asking people do for 10+ years, and they will have a more secure system overall!

[$] A turning point for CVE numbers https://lwn.net/Articles/961978/ #LWN

@jbowen Yes it should, now fixed.

@joshbressers CVE makes it very easy for "one person projects" to be a CNA, so if the CNA process does not scale on their end, I'm sure that's a good problem that the CVE group will be glad to work on.

Anyway, I understand your basic point, but I think the way that other governments are starting to treat open source projects, this is something that everyone is going to have to deal with soon enough.

@krzk May all kernel developer's CVs be filled with CVEs, think of it as an early holiday present :)

@Conan_Kudo @joshbressers Oh, I don't think we are going to have the "not issuing enough CVEs" problem for the kernel, if anything, it's going to be the opposite.

And people shouldn't "fear" a CVE, it's just a hint of "hey, here's a bugfix that might pertain to you!" type of a signal. It's up to the receiver to determine if it does or not.

The main objection the kernel developers had previously about CVEs is that they were NOT an accurate signal at all, and were being totally abused by one company who used them to route around their broken internal engineering practices.

@joshbressers I disagree, open source projects becoming CNAs to prevent others from attempting to dictate what is, and is not, a "security issue" in their software is a key "taking responsibility" step as well as a "preventing others who abuse the CVE process from wasting everyone's time" which is what has been happening to many open source projects for quite a while now.

It really isn't much work to be a CNA, they have made the process very easy, highly recommended for any other open source project to do as well.

@Di4na @joshbressers @kurtseifried @B97 No updates means that there's nothing for you to update to, so again, what's the issue? :)

Seriously, yes, software needs active maintenance, if you rely on it, help provide that maintenance where needed and possible. If no maintenance is possible, then look to use other software instead, or not at all (custom Makefiles are always fun!)

@Di4na @joshbressers @kurtseifried @B97 autotools are great, updating to the latest version is usually a good idea anyway, why wouldn't you want to do that? Many distros do this quite well already, what do they know that others do not?