No, the GP is correct. Data races are undefined behavior, and break memory safety: https://research.swtch.com/gorace

Is there a sense in which Russ's claim that "data races are not security problems" is true? It seems to be assuming that data races are impossible to exploit by users (data input), only by programmers.

Presumably because data races are so inconsistently triggered that creating a reliable exploit would be generally infeasible, even with control over user input. However, this unpredictability is also why data races (among other concurrency issues) are some of the most maddening types of bugs to observe, hunt down, and diagnose, which is why eliminating data races is actually a big deal for anyone who's ever wrestled with threads before.

Go is indeed memory-safe for sequential code, but non-atomic assignment can definitely break memory safety in multi-threaded settings - it's effectively a data race.