Try reading the overview in events.linuxfoundation.org/wp-content/upl. Finding a Linux kernel vulnerability is not hard. Literally hundreds of bugs are found by syszkiller every month and many are not fixed. Most are memory corruption. There are simply too many to even fix all discovered bugs.
Conversation
yes, we don't need to debate the question "can people write memory safe code in C" the answer is overwhelmingly obvious to almost all of us
3
1
18
This Tweet was deleted by the Tweet author. Learn more
If you look through grep's commits, you can see fixes like git.savannah.gnu.org/cgit/grep.git/ and git.savannah.gnu.org/cgit/grep.git/ which did not get a CVE assigned, because it's rare to seek out CVE assignments for each security relevant bug fix. Most projects don't do much of that, or don't at all.
1
1
CVE databases just aren't usable for determining most of the vulnerability fixes going into a project. Linux distributions like Debian relying on CVEs to determine which fixes need to be backported have serious security issues. Greg KH spells this out again and again for Linux.
1
1
1
Also, the Linux kernel having far more CVE assignments than say the FreeBSD kernel doesn't mean it's less secure or had more vulnerabilities. In fact, the lack of security research / fuzzing / dynamic analysis being done to find these bugs in other kernels is a very bad thing.
1
1
Minor nit: Nowadays FreeBSD is being both fuzzed by syzkaller and has clang and other analyzers run against it with the analysis target of bmake, as well as coverty doing static analysis.
Still wouldn't be a bad thing to have more security research being done on FreeBSD, though.
1
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
If you could stop misrepresenting my statements and directly lying about what I said, that would be great. It's incredibly dishonest and not at all fair to post lies about what I said to try to make me look stupid. It's not me that looks bad when you do this kind of thing.