Comment 1:

Labels changed: added priority-go1, removed priority-triage.

Comment 2:

Status changed to Accepted.

Comment 3:

Owner changed to builder@golang.org.

Comment 4:

Owner changed to @dsymonds.

Comment 5:

Other than protection from very large buffer sizes, do you have an actual bug to report?
Gob has protection against "invalid data", although it's likely there are cases that
slip through the cracks. Please be more specific.

Comment 6:

Also, I double-checked and the code has some protection against huge message sizes. With
a specific example it might be possible to harden that further.
It would also be easy to allow programmer control of the upper limit of a message size
or slice, but I am reluctant to do that because of the clumsiness and brittleness that
would result.

Comment 7:

I dropped the max message from 2^31 to 2^30. Moreover, the old code was probably broken
because at 2^31 it could overflow. Please sync, run whatever tests you have, and report
back.

Comment 8:

One obvious thing I thought of is that if a slice or string (or similar) is encoded with
a very large length, and there's not that many bytes in the stream, then there's no
point in allocating memory for what is obviously an invalid message. However, gob is a
stream encoding, so that doesn't make so much sense.

Status changed to WaitingForReply.

Comment 10:

Here's a start with a framework for adding more test types. Kinds of fuzzing could also
still be expanded. It's turned up two bugs though:
gotest -test.run=TestFuzzBug1
panic: runtime error: makeslice: len out of range [recovered]
        panic: interface conversion: interface is runtime.errorString, not gob.gobError
gotest -test.run=TestFuzzBug2
an infinite loop or something that takes a really long time.
It's tricky to build more tests at present because I frequently hit one of these two.

Attachments:

1. fuzz_test.go (1348 bytes)

Comment 11:

Status changed to Started.

Comment 12:

This issue was closed by revision 9440d82.

Status changed to Fixed.