Changes to multi-word pointers can cause UB due to race conditions in Go because only changes at the word level are atomic.
See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
See: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
https://materialize.com/blog/rust-concurrency-bug-unbounded-...
Lockbud: project detailing memory, concurrency bugs and panics for Rust. https://github.com/BurtonQin/lockbud
USENIX paper on model checking for Rust OS kernels uncovered 20 concurrency bugs across 12 modules in projects like Redox OS and Tock, including data races, deadlocks, and livelocks
Go allowing torn writes for their slices and interfaces (their fat pointer types) is intentional behavior in the go implementation and has no sign of being fixed.
Some one getting unsafe code unintentionally wrong is not an indication that any language lacks memory safety.
What about this one ? "Futurelock in Tokyo" ? https://rfd.shared.oxide.computer/rfd/0609
Deadlocks are not memory safety issues by the definition used in the OP. Furthermore, safe Rust is only intended to guarantee protection against data races, not race conditions in general.
'static closures/FnDefs/futures with non-'static return type are unsound https://github.com/rust-lang/rust/issues/84366
Resolve unsound interaction between noalias and self-referential data (incl. generators, async fn) https://github.com/rust-lang/rust/issues/63818
But anyways, at least from a quick glance those would at the very least seem to run into codys' unintentional bug vs. intentional behavior distinction. The bugs you linked are... well... bugs that the Rust devs fully intend to fix regardless of whether any in-the-wild exploits ever arise. The Go data race issue, on the other hand, is an intentional implementation decision and the devs have not indicated any interest in fixing it so far.