> Heartbleed isn't a memory safety issue though, which is what kicked this off.
It kind of is. It's just not of the type that "memory safe" languages fix for you, which is basically the point. If you define the scope of the problem in terms of what the proposed solution fixes then it tautologically fixes the entire problem, but it's still very important for people to understand that that doesn't mean it fixes every problem in that class.
> in C, I could end up executing arbitrary code by misparsing a network packet. In Rust, the worst I'll do is parse it wrong send invalid data onwards.
This is essentially what I'm talking about. It's still possible to execute arbitrary code in Rust, it's just not as easy. An obvious example is if your parsing bug is in the code that validates attacker-provided input before doing something sensitive with it. Or allows the attacker to flip a bit which is equivalent to remote code execution, like giving the attacker's account admin rights.
And even if "the worst" you do is parse it wrong and send invalid data, that's Heartbleed. The "invalid" data could be secrets.
The question you have to ask is, for all those memory corruption bugs in C, what does "memory safe" turn them into? They're still bugs, they're just not the same bugs. For example, a common way you get RCE in C is an integer overflow that leads to a heap overflow when the overflowed integer is used to allocate a buffer. But take away the heap overflow and the integer overflow is still there. Exploiting an integer overflow is highly context-dependent, but it's commonly possible regardless of whether it leads to a heap overflow. Being able to truncate the amount of Bitcoin being debited from the attacker's account or convert "username=rootxxxx" into "username=root" is arguably better than straight RCE, but not by very much.