fix possible memory confusion in unsafe slice cast

[jlauinger]

I found an incorrect cast from string to []byte in reflect2.go. The problem is that when reflect.SliceHeader is created as a composite literal (instead of deriving it from an actual slice by cast), then the Go garbage collector will not treat its Data field as a reference. If the GC runs just between creating the SliceHeader and casting it into the final, real []byte slice, then the underlying data might have been collected already, effectively making the returned []byte slice a dangling pointer.

This has a low probability to occur, but projects that import this library might still use it in a code path that gets executed a lot, thus increasing the probability to happen. Depending on the memory layout at the time of the GC run, this could potentially create an information leak vulnerability.

This PR changes the function to create the reflect.SliceHeader from an actual slice by first instantiating the return value.

[taowen]

you are right

[taowen]

@AllenX2018

[aosting]

reflect2.go forget import "runtime"

[jlauinger]

Yes, I am sorry. there needs to be an import runtime, my bad!

[AllenX2018]

Awesome!