The #Linux #kernel's #CVE team just published their thousandth CVE[1]. 🥳 🙃

This happened 78 days after the effort was announced[2].

Note, 26 of the 1003 CVE entries published so far were later rejected. For details check https://git.kernel.org/pub/scm/linux/security/vulns.git/ or https://lore.kernel.org/linux-cve-announce/

[1] https://git.kernel.org/pub/scm/linux/security/vulns.git/commit/?id=55441d0dd1f40c5762cd7cf8c9ca312ed0964c4a

[2] http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/ #LinuxKernel

@kernellogger FWIW, seems the glorious commit was 066ff875952b ("cves issued for some 6.8.8 commits").

```
vulns$ git ls-tree 066ff87 cve/published/*/*.json cve/rejected/*/*.json | wc -l
1002
vulns$ git ls-tree 066ff87~1 cve/published/*/*.json cve/rejected/*/*.json | wc -l
959
```

And in a way of sorting the CVEs, the 1000th CVE is CVE-2024-27019 (https://lore.kernel.org/2024050150-CVE-2024-27019-e3d4@gregkh).

```
vulns$ git show 066ff875952b --stat
[...]
cve/published/2024/CVE-2024-27019.sha1 | 1 +
[...]
cve/published/2024/CVE-2024-27020.sha1 | 1 +
[...]
cve/published/2024/CVE-2024-27021.sha1 | 1 +
172 files changed, 9150 insertions(+)
```

RE: https://fosstodon.org/users/kernellogger/statuses/112364389830654403

@kernellogger Well, some of those 1000 have been rejected, here's the current stats that anyone can check for themselves in our public git repo by running `scripts/summary` so you don't have to hack up fun `find | wc` chains like you did:

Year Reserved Assigned Rejected Total
2019: 47 2 1 50
2020: 37 13 0 50
2021: 39 304 7 350
2022: 7 43 0 50
2023: 60 180 10 250
2024: 107 435 8 550
Total: 297 977 26 1300


Anything older than 2023 is us back-filling in from the GSD database, and we still have a long way to go for there. Some 2023 ones are in there too from GSD, but mostly not, all of 2024 is since we took over being a CNA.

@gregkh

Thx for the additional details (but FWIW, seems you missed that the toot already had mentioned that 26 were rejected 😬 whatever, easy to miss).

And thx for all your work, too!

@sj

Yeah, I my toot linked to that commit. And reg. the 1000th CVE: I considered going to that level, but then I thought it was not worth it; but thx for doing this, nice to know!

@kernellogger No problem. I was also waiting for the 1000th CVE, and was near to miss it due to an issue in my script. I found it thanks to your post, thank you!

I was also thinking finding the exact 100th CVE is not worthy, but I just wanted some fun ;) Happy to hear that you also got some fun!

@kernellogger @gregkh I was also thinking "But, rejected..." at first, but I soon realized that the rejected CVEs are also a result of the CNA's effort, and therefore should be counted. I also appreciate the CNA's efforts!

@gregkh @kernellogger A 3% false positive rate seems entirely reasonable to me, especially given the volumes involved.

I still don't know what it'll do to my annually created CVE graphs, though. But I'm looking forward to having a whole year's worth of data to look back on. I think we're still at "early days" on this.

@kees @kernellogger Most of the rejects are not "false positives" but rather "Duplicate ID issued due to some company not putting git commit ids in their CVE records so we didn't know not to create this entry."

At least that's what is happening so far on all the rejects in 2023 and older, for 2024, those are actual "false positives" so our numbers look higher than I imagined. Maybe no one is paying attention, which could also be the case...

@gregkh @kees @kernellogger I just reviewed the last month or so of fixes for drivers/gpu and how many you assigned CVEs for. and I think you're still substantially undercounting issues

there's a bunch of things that very much look like they can be used for denial of service stuff, and a bunch of tlb invalidation fixes and other races like that which ... well we learned how to exploit that stuff on the cpu very well, it's not that much harder for gpu. and more

but it's definitely a start

@gregkh @kees @kernellogger I wonder whether a script that sprinkles and later updates CVE annotations over a kernel repo (for a given git rev-list query, otherwise it'll take forever) would be useful for reviewing this all in a year

with that I could just fire up gitk and see which commits are tagged as CVE and which aren't, instead of having to manually compare ...

then a few randomized samples over the relevant subsystem history, and we should have pretty solid data

@gregkh @kees @kernellogger there's also the policy question of whether issues with handling external screens should be counted or not. kinda like hostile usb devices that you can plug in and exploit the kernel with, depending upon exact config

that would substantially blow up the CVE count for drm

@sima @kees @kernellogger I'll gladly assign more, just send me git ids and we can do the rest :)

@gregkh @kees @kernellogger display port has a substantial sidechannel protocol, and hdmi gained that too with 2.0, and desktops tend to autoconfigure new screens so there's a lot of code that just runs automatically

so it's way beyond "EDID parsing bugs" at this point

@gregkh @kees @kernellogger I was more thinking to gather some data, then maybe discuss that next lpc and figure out what we need to do to catch them automatically

because trying to triage this manually is more than a full time job for something like drivers/gpu

@sima @gregkh @kees @kernellogger what is the benefit in tagging 'could maybe possibly be a security issue' to commits when the definition of that is so broad? Is it really beneficial?

Note that it's not just a 'tag' but for enterprise kernels often entails (potentially significant) work in addressing CVEs?

Perhaps a metadata tag would work better? Potentially-Exploitable or such? :)

Given the controversy around CVEs that might be a lighter touch than the gradual move towards treating more and more commits as if they were known security flaws.

@ljs @kees @kernellogger @gregkh eh at least for drivers/gpu my take is that the only thing that works is if you backport the entire subsystem. and even that is very tricky to integrate into an older kernel without issues. otherwise you have schrödinger security because all it takes is someone to get bored enough to type the exploit

and given that rhel does that too I think @airlied is concurring

if the CVE flood is forcing more people towards that model, then I think that's a good thing.

@ljs @kees @kernellogger @gregkh @airlied like imo these bugs aren't "potentially exploitable", they are "I don't have the time to type the exploit and debug it to prove to you that it's exploitable"

and sure people can guess wrong, but from my very quick look for drivers/gpu fixes they're still guessing wrong with a very substantial false negative rate

@sima @kees @kernellogger @gregkh @airlied I don't understand, you should backport the entire subsystem constantly? How can that possibly work?

And at that point why are you tagging anything?

Forcing more people into what model?

@sima @kees @kernellogger @gregkh @airlied I mean if you're picking things that are genuinely exploitable then fine.

The issue comes with the reductio ad absurdum of 'if it fixes something then let's assume it's a reportable security flaw', which seems to be the current approach to kernel CVEs (and hence the controversy).

@ljs @airlied @kees @kernellogger @gregkh a few stable kernels at most is the limit for backporting individual patches for drm. beyond that, it's just wishful thinking and yes, you're better off backprting the entire subsystem

imo for drm already lts kernels are an illusion

@ljs @airlied @kees @kernellogger @gregkh well my take, from a quick look at least, is that for drm the current approach still undercounts the patches that I think are clearly exploitable.

there is a wide set of patches where it's hard to make the call without in-depth analysis, especially in the rather complex modeset paths. but a few fixes on the gem side are obvious exploit material on a pure design analysis basis

@ljs @airlied @kees @kernellogger @gregkh plus the kernel has no internal isolation, so even if it's not a full exploit on its own, a lot of the patches without cves I looked at are very useful tools to exploit otherwise harmless bugs elsewhere

@sima @gregkh @kees @kernellogger like the ioctl deadlock I was fixing in nouveau: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/nouveau?h=v6.9-rc6&id=daf8739c3322a762ce84f240f50e0c39181a41ab

@gregkh @sima @kees @kernellogger The "C" in "CVE" is for "candy". 🍬