Repository navigation
math/rand/v2: ChaCha8.UnmarshalBinary panics on an overlong read buffer #81488
Description
(*ChaCha8).UnmarshalBinary accepts a length-prefixed readbuf: field longer than its eight-byte buffer, then panics while slicing the buffer instead of returning an error. It also updates the buffered bytes before validating the remaining state, so a failed unmarshal can change subsequent Read output.
c := rand.NewChaCha8([32]byte{}) // rand is math/rand/v2
_ = c.UnmarshalBinary([]byte("readbuf:\x09123456789")) // slice bounds panicDetails
In src/math/rand/v2/chacha8.go, UnmarshalBinary executes c.readLen = copy(c.readBuf[len(c.readBuf)-len(buf):], buf) before calling chacha8rand.Unmarshal. The length-prefix helper accepts lengths from 0 through 255 if enough bytes follow. A nine-byte buffer makes the slice start at −1, before the core state is checked.
A shorter buffer avoids the panic but is committed even if the remaining state is invalid. On a fresh generator, the following rejected encoding injects POC into the next read:
err := c.UnmarshalBinary([]byte("readbuf:\x03POCnot-a-valid-chacha8-state"))
var out [3]byte; _, _ = c.Read(out[:]) // err != nil; string(out[:]) == "POC"This issue was found by zkao and was triaged by @FiloSottile as a valid bug but not a vulnerability. /cc @golang/security
Activity
gabyhelp commentedon Sep 13, 2026
Related Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
cristiangirlea commentedon Sep 16, 2026
I'd like to work on this. I can send a small fix that rejects oversized read buffers and leaves the generator unchanged when decoding fails, with regression tests for malformed inputs and valid round trips. Would it be OK for me to take this, or is someone already working on it?
gopherbot commentedon Sep 16, 2026
Change https://go.dev/cl/833564 mentions this issue:
math/rand/v2: validate ChaCha8 encodings before changing state