@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:
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@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
@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
@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@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
Add comment