Reject a hostile Content-Length instead of panicking

[objevovat]

The bug

A receiver answering with Content-Length: -1 crashes the sender.

parseHTTPHeader reads the value with Sscanf into an int and doesn't check it. In readPlaintextHTTPResponse the zero case is handled, but a negative value falls through to:

body := make([]byte, contentLength)   // panics: makeslice: len out of range

Nothing recovers it. I reproduced this end to end over a net.Pipe standing in for the receiver — the panic happens inside readPlaintextHTTPResponse, not in a helper.

Also bounded the positive case

Content-Length is receiver-controlled and was used unbounded, so Content-Length: 2147483647 asks the sender for a 2 GB allocation before a single body byte arrives. Control-channel bodies here are small plists, so the 8 MB limit is far above anything legitimate and far below anything that hurts.

Scope

Only these two sites. I checked the other four make([]byte, n) in the package and left them alone:

• readEncryptedFrame already bounds its uint16 length and rejects anything over 16384
• hkdfSHA512 and padTo take caller-supplied sizes, not network values
• audio.go's n comes from a Read, so it can't be negative

Tests

Negative, large-negative and oversized headers, plus a well-formed response to show the normal path still reads its body. Removing the guard makes the first two fail with the original panic, so the tests genuinely cover it.

go test ./... is green.

How I found it

I was fuzzing the receiver-facing parsers — parseHTTPHeader, parseTXT, parseFeatures, parseCaptureFrames, parseXrandrGeometry — for about 11.8 million executions total. All clean; none of them crash. This one isn't reachable by fuzzing those functions in isolation, because the panic is at the use of the parsed value rather than in the parse. It turned up reading the allocation sites afterwards.

Happy to contribute the fuzz targets separately if you'd want them in the tree.

[omarroth]

Great, thanks!