The latter. It's trivial to reuse buffers in Rust while avoiding this issue, for example `Vec` has a `clear` method that sets the length to 0 while keeping the allocation.
But AFAICT, in C it didn't even have the same buffer by design, it was reading uninitialized memory from whatever `malloc` gave it back - which is equivalent to allocating a new buffer in Rust.
It was actually using a custom allocator, not the system malloc, which exacerbated the problem. System malloc could still have this problem, but for example OpenBSD has mitigations for this sort of data leakage in their malloc implementation, which OpenSSL then bypassed by using their own allocator.
This is a problem for any "this would never happen in Better Language X" claim regarding Heartbleed. If you decide you want to write your own buffer reuse system for whatever reason, you can pretty easily write this sort of bug in any language.
I would argue that the whole Rust ecosystem pretty strongly discourages you from writing broken low-level infrastructure code. The idea behind unsafe code blocks, the generics system, and Cargo is to encourage you to use off-the-shelf tools instead of rolling your own, often broken, solutions. The C ecosystem, by contrast, tends to encourage rolling your own solutions because managing dependencies in a cross-platform manner is such a pain (and the language doesn't help due to the lack of generics and so forth). I suspect that any free-list library in Cargo that didn't zero out buffers would be fixed pretty quickly (and, as eddyb rightly points out downthread, it would be pretty hard to write a free list system that works with multiple types that doesn't require initialization before use--Rust in general abhors uninitialized memory).
There are parallels between the philosophy of crypto libraries like NaCl and Keyczar and the Rust philosophy. Don't write your own low-level infrastructure code. Use somebody else's.
And in fact, I've written that exact thing in a C# network stack, about 7 years ago. No bug, as I did properly check the size of the data, but totally possible to have messed up. It's not even hard code to write, just a simple object pool to return byte arrays. Which is natural, as in .NET, high performance often ends up as an exercise in removing every heap allocation possible.
That said, this is a fair point. I have shot myself in the foot in a fairly equivalent manner in another memory-safe language (doesn't really matter which) because I was trying to reuse buffers as an optimization. Oops. I did it to myself, and at least I understood enough about what was going on that I didn't spend days wondering at the heisenbugs, but still, oops. It can happen.
But AFAICT, in C it didn't even have the same buffer by design, it was reading uninitialized memory from whatever `malloc` gave it back - which is equivalent to allocating a new buffer in Rust.