I found an incorrect cast from []byte to string in models/inline_strconv_parse.go. The problem is that when reflect.StringHeader 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 StringHeader and casting it into the final, real string, then the underlying data might have been collected already, effectively making the returned string 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.StringHeader from an actual slice by first instantiating the return value.
I found an incorrect cast from
[]byte
tostring
inmodels/inline_strconv_parse.go
. The problem is that whenreflect.StringHeader
is created as a composite literal (instead of deriving it from an actual slice by cast), then the Go garbage collector will not treat itsData
field as a reference. If the GC runs just between creating theStringHeader
and casting it into the final, real string, then the underlying data might have been collected already, effectively making the returned string 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.StringHeader
from an actual slice by first instantiating the return value.