> At this point, there are probably very few in linux after the level of fuzzing its received.
Linux is heavily developed, which means significant code churn. It's a victim of its own success.
And there's much less fuzzing happening than you think. It's an on-again, off-again activity; not something that any particular organization (AFAIK) is rigorously and repeatedly performing on Linux for any serious length of time (i.e. years). Fuzzing isn't an automatic thing; it requires human intervention to help craft the tests so they reach and tickle the right corner cases. And if the code is constantly changing, you need to constantly review your tests.
Also, syscall fuzzing must be done differently from network fuzzing, for example. And fuzzing kernels in general is more difficult than, e.g., a self-contained library.
If you look at the Linux kernel CVEs, they've been steadily increasing over time: https://www.cvedetails.com/product/47/
We can quibble over the causes and significance, but I don't think those data points support your argument.
Yes, remote exploits in Linux are rare, just as they're rare in most operating systems, including macOS and Windows. But not rare enough. And there's little indication that they're becoming more rare. Unfortunately, I'll bet that the shift to eBPF to implement basic filtering and routing will cause a spike over the next few years.
At this point the Linux kernel is a lost cause. Everybody serious about security understands that the future is moving your most sensitive assets to secure enclaves not running general purpose OSs like Linux. Unfortunately those enclaves are recapitulating the same mistakes--too many features, too flexible, too much emphasis on adding more complexity to try to fix things. But one thing is certain, Linux is definitely not getting any simpler, and people are moving assets to slower moving train wrecks.
> If you look at the Linux kernel CVEs, they've been steadily increasing over time [...] I don't think those data points support your argument.
The number of CVEs don't support any argument really. More CVEs are assigned, yes. That doesn't mean more security issues. In the olden days of 8 years ago, a buffer overflow would be patched with no fanfare and no CVE assigned. Nowadays, often only theoretically exploitable issues will still be given a CVE.
That's the interesting thing about the approach used to find this bug (automatic variant analysis): whilst there are no doubt more bugs to find in XNU, there aren't any more bugs like this.
The article says that the problem was found by codifying the mistake that led to a previous CVE as a query in a logic language called QL, and then running that query over XNU, so if there were any more they would have been found at the same time.
