SIPGO is a library for writing SIP services in the GO language. Prior to 1.4.3, WSConnection.Read in sip/transport_ws.go creates a wsutil.Reader without setting MaxFrameSize, allowing NextFrame to accept a client-controlled header.Length before ParseMaxMessageLength is applied. An unauthenticated WS or WSS peer can send a frame header declaring an extremely large payload, causing an oversized allocation or a makeslice length panic before the payload is read and crashing or exhausting memory in the server process. This issue is fixed in version 1.4.3.

Affected: Go: github.com/emiago/sipgo

### Summary

The WebSocket transport allocates a buffer from the frame payload length before validating its size, which can lead to an unauthenticated DoS.

### Details

`WSConnection.Read` allocates a buffer from the declared WebSocket frame length before reading the payload (https://github.com/emiago/sipgo/blob/v1.4.0/sip/transport_ws.go#L400):

```go data := make([]byte, header.Length) // header.Length is client-controlled, up to 2^63-1 (int64) ```

- `NextFrame()` reads only the frame header and never checks the length: `wsutil.NewReader` is created with no [`MaxFrameSize`](https://pkg.go.dev/github.com/gobwas/ws@v1.3.2/wsutil#Reader.MaxFrameSize) (`0` = unlimited). `ParseMaxMessageLength` applies only downstream, not here. - A value above the max slice size (e.g. `2^63-1`) panics `make`. sipgo does not recover from this panic, so it crashes the whole server process.

### PoC

Tested on emiago/sipgo v1.4.0 (latest).

After a normal WebSocket handshake, send one masked text frame consisting of the header only (no payload), declaring a huge length. The allocation runs as soon as the header is read.

``` 0x81 FIN + text opcode 0xFF MASK bit + length marker 127 (8-byte length follows) 0x7F FF FF FF FF FF FF FF declared length = 2^63-1 -> make panics (crash) <4-byte masking key> (no payload) ```

This crashes the server process:

``` panic: runtime error: makeslice…