This is quite the... unique way of defining "undefined behavior". Rust is currently implementation-defined. That doesn't even remotely mean its behavior is undefined in theory. And it certainly doesn't mean that "all of Rust" is UB in any practical, real-world sense. In practice, your average Rust program is more well-defined than nearly every C codebase, in terms of what invariants the compiler is allowed to assume about the code for the sake of performing transformations (which is what UB actually means, rather than "is there an international standard").
Many cases of UB in C are perfectly well defined at the implementation level. Some are not, for reasons ranging from lack of a demand signal, to the need for an expensive runtime, to compiler writers wanting to squeeze out every last drop of performance.
I'm sorry for being pedantic, but it's important to distinguish between UB generally (which would normally be termed "implementation-defined" in common parlance if that weren't already a term of art) and memory safety specifically.
We don't get CVEs because a C source file didn't end in a newline. I suspect we rarely get CVEs because someone failed to add -ftrapv when they should have. We get CVEs primarily due to OOB memory access.