The proposal regarding prevention of memory-related faults is that Rust addresses 70% of the causes of issues:
...in Rust, 70% of these security issues would most likely have been eliminated.
Why Rust for safe systems programming
It's no statement about Rust's leadership in memory safety if one of the other 30% is found:
At some point code must manage and access memory.
.NET uses assembly language in the runtime:
runtime/src/coreclr/runtime/amd64 at main · dotnet/runtime
.NET uses C++ in the garbage collector:
runtime/src/coreclr/gc at main · dotnet/runtime
.NET uses C for the native AOT:
runtime/src/native/minipal at main · dotnet/runtime
Rust uses LLVM which (unless/until rewritten in Rust) uses C and C++. Some Rust crates encapsulate unsafe code that operates with memory.
Any language's memory safety and management strategy cannot avoid the necessity of some software managing and accessing memory. The key is a hierarchy whereby memory operations are isolated to compilers/toolchain (e.g. Rust, and few others, if any), lower-levels, and crates/libraries. Rust and .NET, both recommended by CISA, are no different in this regard. The difference is that Rust does it without the performance overhead of a runtime, a JIT, and a garbage collector.
Rust is superior in memory safety to C and C++. That doesn't mean that in the software world, memory is never accessed. So, engineers that work on these isolated sections of code, must still be knowledgeable and careful.
Note the article of OP:
...This marks the first publicly disclosed Rust kernel exploit,...
The first one exposed is overflow. The source code accessed memory outside of the valid memory space. This is not a malloc/free scenario. This is one of the other 30%. The first exploit disclosed, does not relate to Rust's specialty (unless someone's not disclosing prior exploits of the category of the other 70%, extremely unlikely). This is a good sign, that Rust is working as intended.