Client recv_buffer lacks staging cap allowing 64 MiB retention per connection

[cursor]

Severity

Medium

Location

src/client/mod.rs

Attacker

A malicious or compromised RTMP server that the embedder connects to for playback or during the AMF command wait in connect / publish / play.

Controlled input

Sustained inbound TCP data delivered faster than the client drains complete messages from recv_buffer, especially when per-poll message budgets defer processing.

Attack path

1. Victim application connects to an attacker-controlled RTMP server and enters Client::poll() (playing) or recv_message() during AMF command wait.
2. Inbound bytes append to recv_buffer via Buffer::write on each socket read.
3. Unlike Conn::recv() on the server (capped at 2 * DEFAULT_MAX_MSG_LENGTH = 8 MiB after issue Per-connection recv_buffer can grow to 64 MiB when message budget exhausts before draining #97), the client had no staging cap beyond the global BUFFER_MAX_SIZE (64 MiB).
4. A server that keeps the kernel recv queue full across many poll iterations can retain up to 64 MiB of incomplete wire data per client connection.

Impact

Memory exhaustion against embedder processes: each targeted client connection can hold up to 64 MiB in staging buffers. An attacker operating a malicious RTMP server can multiply this across reconnecting clients.

Remediation

Mirror the server-side MAX_RECV_BUFFER_BYTES staging cap (2 * DEFAULT_MAX_MSG_LENGTH) in Client::poll() and recv_message() before appending new socket data to recv_buffer.

[AlexanderWagnerDev]

Fixed by #105 (merged): Client::poll() / recv_message() now cap recv_buffer staging at MAX_RECV_BUFFER_BYTES (2x DEFAULT_MAX_MSG_LENGTH plus chunk-header-overhead headroom), mirroring the server-side cap.

---

Generated by Claude Code