Comment by throw329084
11 hours ago
This blog post, brought to you by the man who wants to burn down the CVE system https://lwn.net/Articles/1049140/
11 hours ago
This blog post, brought to you by the man who wants to burn down the CVE system https://lwn.net/Articles/1049140/
I, this last week, had to spend hours dealing with a fake CVE that was opened 2 years ago on an open source dependency of our project for a bug that amounts to "if you have RCE, you can construct a malicious java datatype and call this function on it to trigger a stack overflow". The github thread on the lib is full of the maintainers having to deal with hundreds of people asking them for updates on an obviously fake CVE. Yet the CVE is still up and has not been deleted. And I now get a request from a customer about fixing this vuln in our code their CVE scanner found.
The CVE system is broken and its death would be a good riddance.
One of the many people who know the CVE system is elaborately broken in many ways.
Please, tell me what issues you have with how the kernel does CVEs.
Not op but if you are looking for information on why sone people arent keen on the kernels approach to CVE management https://jericho.blog/2024/02/26/the-linux-cna-red-flags-sinc... might be of interest
To be fair the CVE system can't even encode a version string
Not sure whether this is a limitation of the scanning tooling or of the CVE format itself, it also cannot express sub packages. So if some Jackson-very-specific-module has a CVE the whole of Jackson gets marked as impacted. Same with netty.