What about the commit message for the fix [0] makes you think this code, if it were written in say... rust, wouldn't have just been put in an unsafe block to do the "opportunistic" e.g. fast and dirty thing, anyways?
When your development practices normalize cheating here and there for performance wins where it matters, any language capable of writing kernels isn't going to stop you.
The wording `unsafe` makes it very obvious that it is supposed to be a method of last resort. In C, it is very easy to accidentally drift into undefined behavior, and reviewers have to be aware of all the potential issues, which can occur everywhere. Rust's `unsafe` blocks at least make it obvious where exactly dangerous things are going on so refers can focus their attention there. And the Rust compiler still performs many checks inside `unsafe` blocks, most importantly borrow checking.
Its very rare for only one exploit to be used when a system is compromise. Multiple exploits will be used, one for entry, one for escalation of privileges, etc.
Rust hardly deals with memory race conditions better than C, and managed languages are not fit for kernel. This isn't the fault of C at all. These kinds of issues are unavoidable part of kernel programming in multiprocessor settings and not something you can solve with a different programming language.
Rust deals with race conditions 100 times better than C. Have you tried it? Just because it can't guarantee that they never happen doesn't mean it isn't any better.
You can't solve this with a different programming language but you can definitely make bugs much less likely.
