Conversation
sj
sj
Because my airplane was delayed, I played with kernel CVE data, and summarized[1] the buggy and error-full results.
TL; DR: About 95% of CVEs that affect the mainline tree has fixed before those are reported by linux_kernel_cves project. The number was 76%, 69%, 73%, 78%, 83% and 82% for 6.4.y, 6.1.y, 5.15.y, 5.10.y, 5.4.y, 4.19.y, and 4.14.y, respectively.
The worst case time between linux_kernel_cves report and fix commit being fixed was [16, 32) weeks for the mainline. For the stable trees, the number was [4, 8) weeks (6.4.y), [16, 32) weeks (6.1.y and 5.15.y), [32, 64) weeks (5.10.y), [64, 128) weeks for 5.4.y, [32, 64) weeks (4.19.y and 4.14.y).
[1] https://github.com/sjp38/lazybox/blob/master/cve_stat/report/report.md
#linux #kernel #cve #stable #lts
TL; DR: About 95% of CVEs that affect the mainline tree has fixed before those are reported by linux_kernel_cves project. The number was 76%, 69%, 73%, 78%, 83% and 82% for 6.4.y, 6.1.y, 5.15.y, 5.10.y, 5.4.y, 4.19.y, and 4.14.y, respectively.
The worst case time between linux_kernel_cves report and fix commit being fixed was [16, 32) weeks for the mainline. For the stable trees, the number was [4, 8) weeks (6.4.y), [16, 32) weeks (6.1.y and 5.15.y), [32, 64) weeks (5.10.y), [64, 128) weeks for 5.4.y, [32, 64) weeks (4.19.y and 4.14.y).
[1] https://github.com/sjp38/lazybox/blob/master/cve_stat/report/report.md
#linux #kernel #cve #stable #lts
2
1
3
@sj Since CVEs are basically useless, any percentage here or calling it "worst case time" is pointless. It's like measuring number of celebrities and mapping it to Linux kernel commits... Worse, it suggests that some bugs are not addressed (not fixed) or addressed slowly. This is in fact misleading.
1
0
1
@krzk I personally agree many parts of your points. But I also know there are many different opinions and believes about CVEs. I hoped these numbers to be no more, no less but only somewhat can help more people to get dry facts that can all agree upon and further make constructive discussions, and therefore shared. I'm sorry if you felt this post in such a way.
1
0
0
@sj Just in case - I was not offended and I just discuss the idea of measuring anything against CVEs.
I believe that in open-source work we should not be participating in this ridiculous CVE dance, unless of course it's our profession or job. Then... well, life. :) It was my job once too.
I understand why CVEs were invented and why they are still used, even though they were effectively made pointless in last few years. However, just because some corporations believe in them ("believe" is a key word here, because their decision about CVE was based on feelings not facts), does not mean we should be endorsing this or participating in this.
I believe that in open-source work we should not be participating in this ridiculous CVE dance, unless of course it's our profession or job. Then... well, life. :) It was my job once too.
I understand why CVEs were invented and why they are still used, even though they were effectively made pointless in last few years. However, just because some corporations believe in them ("believe" is a key word here, because their decision about CVE was based on feelings not facts), does not mean we should be endorsing this or participating in this.
1
0
1
@krzk @sj Also note that the largest generator of CVEs for the kernel is RH doing so for their kapot engineering process which requires a CVE to be created to backport a patch easier to their old "enterprise" kernel tree. That means they are usually creating new CVEs for issues we fixed months/years ago. Hopefully one day they fix their process (I document it in detail in the presentation @krzk linked to above).
3
21
18
@gregkh @krzk I surely understand and agree with many of you, and Greg's points :) I am also aware of the talk and recent maintainers summit discussion. Actually the discussion was one of the major motivations for writing the scripts. https://github.com/sjp38/lazybox/blob/master/cve_stat/report/report.md. Again, I only hope these numbers to be useful for discussions between people having different opinions about CVE, or at least me. Thanks to @gregkh for reminding me the RH case again. That will be helpful for me to discuss with others :)
0
0
0
@siddhesh_p @gregkh @sj Yeah, maybe they do not require CVE for every backport anymore... but then:
"Heh, apparently Red Hat recently assigned a CVE for a random kernel fix I did 7 years ago"
so not really.
https://mastodon.social/@vegard/110933167051678536
"Heh, apparently Red Hat recently assigned a CVE for a random kernel fix I did 7 years ago"
so not really.
https://mastodon.social/@vegard/110933167051678536
1
0
1
@siddhesh_p @gregkh @sj Independently? Something fixed 7 years ago? How can you trigger such bug?
I can barely believe that any customer discovered now a bug which was fixed 7 years ago. Even if this is possible, I can hardly believe any sane person on distro side would request for CVE for such bug, instead of replying: "dude, you forgot to update your system for the last 7 years".
So no, much more likely is that RedHat was actually shipping some crazy old kernel to some people without that fix and needed CVE to justify touching this old stuff...
I can barely believe that any customer discovered now a bug which was fixed 7 years ago. Even if this is possible, I can hardly believe any sane person on distro side would request for CVE for such bug, instead of replying: "dude, you forgot to update your system for the last 7 years".
So no, much more likely is that RedHat was actually shipping some crazy old kernel to some people without that fix and needed CVE to justify touching this old stuff...
1
0
0
@siddhesh_p @gregkh @sj You did not really cover the case. Either this customer had outdated kernel, thus the group should not even start creating CVE, or this kernel did not have basic fix which was fixed 7 years ago. In the latter case it would be enough just to backport the fix, not go through ridiculous CVE assignment.
Anyway, it is not really professional and what RedHat is doing with CVEs is awesome example how useless CVEs are.
Anyway, it is not really professional and what RedHat is doing with CVEs is awesome example how useless CVEs are.
1
0
2