And that category of bugs (memory safety) is only avoidable if the unsafe code itself doesn't have undefined behavior (which responsibility is left to the programmer rather than the compiler). If unsafe code is compromised then it's still game over (hence the recent development of various tools/methods like Stacked Borrows in MIRI that checks potential errors outside the borrow checker, as well as various guidelines for developers to write safer unsafe code)

Safe Rust cannot ever cause undefined behavior, but Unsafe Rust can. The ultimate merit of Rust is that when you suspect any undefined behavior you only need to check the unsafe part, which is a much smaller percentage of your codebase (as opposed to C/C++ where you need to check the entirety of your code)

It is not enough to check your unsafe code for UB, you also need to make sure it does not violate the invariants Rust relies on to prove the safe code safe.

...which I consider as one of the bullet points in the list when checking UB in unsafe code.

????

Whatever that means lol

You mean the borrow checker? People are working on formally proving that, and have already done so for large subsets of the language.

They mean that in unsafe code, you have to adhere to some rules to prevent safe code from becoming unsafe.

In other words, incorrect code in "unsafe Rust" can cause safety issues that only appear when you use it in a certain way from "safe Rust".

a very narrow sense representing 70% of all security vulnerabilities at microsoft and google (self-reported). i'd say it's a class of vulnerabilities worth eliminating, especially when the "cost" is getting a competent and standard package manager and a general focus on correctness that ultimately increases developer productivity and ergonomics (compared with C++, IME)