Linux CVEs, more than you ever wanted to know
39 points
7 hours ago
| 3 comments
| kroah.com
| HN
1vuio0pswjnm7
2 hours ago
[-]
reply
paulryanrogers
6 hours ago
[-]
Looking forward to posts links in the series. This seems like a bit of a tease.
reply
dredmorbius
6 hours ago
[-]
2nd 'graph of TFA links five talks on the topic all within the past two years.
reply
paulryanrogers
3 hours ago
[-]
Perhaps I misunderstand, but aren't those far above the "So here’s a series of posts" and its bullet list?
reply
throw329084
6 hours ago
[-]
This blog post, brought to you by the man who wants to burn down the CVE system https://lwn.net/Articles/1049140/
reply
accelbred
57 minutes ago
[-]
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.

reply
TheDong
1 hour ago
[-]
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.

reply
DeepYogurt
3 hours ago
[-]
To be fair the CVE system can't even encode a version string
reply