Use after free in api/memory.go::receiveSlice

[reuvenpo]

In the receiveSlice method under api/memory.go the call to free_rust, followed by returning the slice at res immediately triggers a use-after-free in cGet and cSet.
Note that GoByes does not copy the slice contents
EDIT: I was wrong, GoBytes does perform a copy. The rest of this issue is still valid though.

This is a more fundamental issue than just removing the call to the free_rust function. The Buffer type which is used here probably represents a wrong approach to passing buffers across FFI between Rust and Go.

I personally don't know the capabilities of the Go runtime and type system that well, so I think that the best approach would be to pass equivalents to Rust's &[u8] type across the FFI boundaries, and copy the contents of the slices when receiving them on each side. Since Rust has a richer type system, we can probably also wrap go byte arrays in a type similar to Vec<u8> which implements AsRef<[u8]> and calls a go destructor across FFI on drop (but i don't know how to do that off the top of my head in Go).

Implementing this correctly will allow returning arbitrarily long buffers back in impl ReadonlyStorage for DB, impl Storage for DB, and impl Api for GoApi

P.S. the Buffer::read method should be marked unsafe, even today, for the same reason that consume is.

[reuvenpo]

I checked with a friend that has more experience in Golang. Apparently i can't read, but the documentation linked above is quite vague. The GoBytes method DOES copy the contents of the slice. The linked paragraph mentions this method, and the explains how one would create a bytes object without copying it, using a different method.

[reuvenpo]

This means that if the UAF is there, it's more subtle than the one i described, but the rest of my points still apply.

[reuvenpo]

The points brought up in this Issue have been either addressed in PR #67 or better thought out in this comment. @ethanfrey @webmaster128 I think you can close this issue.