May 26, 2021 CWE-416: Use After Free
May 26, 2021 CWE-457: Use of Uninitialized Variable
There are numerous others that follow including out-of-bounds reads, overflows, etc. I can't imagine where you got the idea that this somehow "hasn't ever really been" a problem for curl.But likely you were thinking of mod_ssl. Except, mod_ssl is how Apache ends up using OpenSSL, where the famous Heartbleed bug is literally exactly the sort of memory unsafety that you'd never do in Rust.
Putting Rust into kernel seems to me that is a lot of effor for microscopic gains.
Although it would be great to eventually see it.
Linux is thirty years old. And Linux isn't something from whole cloth, it's a Unix, it didn't have some legal and technical baggage that UNIX® brand Unix had but it's a Unix. And Unix is over sixty years old.
We may very well be done. Unix isn't the best conceivable Operating System, but it seems like it's good enough, and in being good enough it became so enormously popular that any new alternative has to be night-and-day better or why bother?
I'm reminded of the Two's Complement Integer thing. Historically it was unclear if this was the "best" way for integers to work. Hardware existed, and sold well decades ago, with some other ideas for how integers could be represented and calculated. But, gradually, over time, even if Two's Complement wasn't clearly the best, it was clearly the most popular, and the others weren't clearly better so why fight it? Sure enough, "Two's Complement Integers" get to just be how integers work by default in newer languages.
If Linus and all the subsystems people were screaming "Nothing but C, under any circumstances" then perhaps you could imagine a competitor to Linux comes along in ten, twenty, thirty years. But so long as they remain open to changes that actually have good results, they're going to stay on top.
Considering Google's funding of these ISRG projects, I hope this changes.
On aspect of the Rust-on-Linux worked I've helped out with is trying to make sure standard library abstractions aren't just suitable for userspace. I hope the medium term result of this is more comparability between bare metal projects on axes where they aren't trying to differentiate.
Longer term, I hope that means a corpus of driver that can be shared between kernels, revolutionizing kernel diversity the same way LLVM revolutionized programming language diversity.
The Linux kernel project sounds interesting. It would be nice if there was an effort to purge as much C code as possible from the core of the kernel and really enforce standards such that even a maliciously designed kernel module should not be vulnerable to memory corruption bugs.