Commit 4e0cd1ee authored by Kevin Burke's avatar Kevin Burke Committed by Brad Fitzpatrick

database/sql: clone data for named []byte types

Previously named byte types like json.RawMessage could get dirty
database memory from a call to Scan. These types would activate a
code path that didn't clone the byte data coming from the database
before assigning it. Another thread could then overwrite the byte
array in src, which has unexpected consequences.

Originally reported by Jason Moiron; the patch and test are his
suggestions. Fixes #13905.

Change-Id: Iacfef61cbc9dd51c8fccef9b2b9d9544c77dd0e0
Reviewed-on: https://go-review.googlesource.com/22393Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
parent a20fd1f6
......@@ -217,7 +217,12 @@ func convertAssign(dest, src interface{}) error {
dv := reflect.Indirect(dpv)
if sv.IsValid() && sv.Type().AssignableTo(dv.Type()) {
dv.Set(sv)
switch b := src.(type) {
case []byte:
dv.Set(reflect.ValueOf(cloneBytes(b)))
default:
dv.Set(sv)
}
return nil
}
......
......@@ -377,3 +377,15 @@ func TestRawBytesAllocs(t *testing.T) {
t.Fatalf("allocs = %v; want max 1", n)
}
}
// https://github.com/golang/go/issues/13905
func TestUserDefinedBytes(t *testing.T) {
type userDefinedBytes []byte
var u userDefinedBytes
v := []byte("foo")
convertAssign(&u, v)
if &u[0] == &v[0] {
t.Fatal("userDefinedBytes got potentially dirty driver memory")
}
}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment