@vbabka Hey, we get some wrong, I thought this was a real "BUG" output, which would have deserved a CVE. Now rejected, if you notice us messing things up at times, let us know! We've already rejected a bunch, here's our current stats after just a few weeks doing this:

Year Reserved Assigned Rejected Total
2019: 47 2 1 50
2020: 37 13 0 50
2021: 45 205 0 250
2022: 45 5 0 50
2023: 51 145 4 200
2024: 502 48 0 550
Total: 727 418 5 1150

Majority so far is back-filling in from the GSD entries. We've only really done 2-3 stable releases so far, we have a bunch of review to catch up with, you can see the current status in our git repo if people are curious what is being discussed/reviewed.

@vbabka

@clacke @joshbressers @kurtseifried @ljrk Yes, that is a good overview, and you can point at the managers and developers on the Google Android team for doing all of this hard work both in convincing people that this was a good idea, and actually doing the work to get stuff merged properly. I've watched them do this for the past 10+ years, it wasn't easy but has paid off a lot in my opinion, the security level of an Android device is worlds better than it used to be because of this effort.

I feel terrible, but I haven't laughed this hard in a long time.

@gromit @kernellogger @matttbe #kernelnewbies is great, I've been on there for a _very_ long time.

@sj @kernellogger @kees https://git.kernel.org/pub/scm/linux/security/vulns.git/commit/?id=85cc68a7c37e367954e295a765da45a62e23f8f5 Now fixed.

@sj @kernellogger @kees Oops, need to fix that up, the repo is now handling "live" data, that is a hold-over from when it was just testing data...

@kees What @kernellogger said, I would love to see patches sent for the stuff we have there!

@matttbe @kernellogger We've been on irc for decades, we are everywhere :)

@ljrk @joshbressers @kurtseifried The core Android portion of Google is very much NOT out-of-tree, they merge their code upstream almost always first before applying it to older Android kernel branches. See the yearly report at the Linux Plumbers conference for the past 5+ years where they what has been merged, what is left to be merged, and what is coming next, with pretty graphs and the like.
They have a strong "Get your changes upstream first" rule with their OEMs and you can see the interactions with those companies uptream has increased dramatically over the past years been because of this.

ChromeOS portion of Google also has a strong "upstream first" rule, and is very good about taking updates and getting changes merged properly.

The Pixel out-of-tree stuff is due to other "reasons", but that is a separate division and there have been many patch submissions recently upstream to resolve that delta, so that is being whittled down.

@ljrk @joshbressers @kurtseifried Based on the Android work I've seen happening, I doubt it. We have successfully run Pixel6 on every Linus -rc release for the past 3 years and that had 300+ out of tree drivers, not an issue. If you want to keep your code out of tree, you can, it just costs you money to do so, which companies have long understood for many decades now, it's their business decision. CVEs aren't going to change this at all, it does not affect the rate-of-change of upstream and stable releases at all.

@ljrk @kurtseifried @joshbressers It does not affect anything at all about in-kernel apis, there is no such stability rules or requirements, rather the opposite.

@joshbressers Not a problem, glad someone is looking at the records! :)

@kernellogger Your data is going to be a bit skewed here, we have ONLY processed the v6.7..v6.7.1 and most of the v6.7.1..v6.7.2 commits so far for CVE-related stuff, which by far the majority have only Fixes: tags due to my travel schedule during those releases (i.e. I didn’t have the cycles to catch up with the cc: stable@ tagged commits. I bet the numbers will level out over time as we catch up with the rest of the commits in the v6.7.Y releases.

And it’s good to see people paying attention, thank you!

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.