Mint HTTP/2 client buffers oversized frames up to 16 MiB before enforcing max_frame_size

Summary

Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to make the client hold up to about 16 MiB per connection in frames it should reject, consuming client memory.

Mint.HTTP2.Frame.decode_next/2 in lib/mint/http2/frame.ex compares a frame with the client's max_frame_size (16,384 bytes by default) only once the whole declared payload has arrived. Until then it returns :more, and Mint.HTTP2 keeps every received byte in the connection buffer. A server can declare a frame length of up to 16,777,215 bytes and withhold the last byte, keeping roughly 1,024 times the advertised limit buffered for as long as the connection stays open. The server has to send every byte the client buffers, so there is no amplification, and the buffer stops at the 24-bit frame length limit.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Late size check. Mint.HTTP2.Frame.decode_next/2 calls decode_next_raw/1, whose binary pattern only matches once the full declared payload is present. The max_frame_size guard runs on the matched payload, so a partial frame of any declared length returns :more.

2. Unbounded buffering. On :more, Mint.HTTP2.handle_new_data/3 stores the accumulated data in conn.buffer, and maybe_concat_and_handle_new_data/2 prepends it to every later socket read, in both stream/2 (active mode) and recv/3 (passive mode). Nothing caps the buffer.

3. No release. Mint has no idle timer. In active mode the buffer is held until the caller closes the connection. In passive mode a recv/3 timeout closes it, but a server that sends a byte within each timeout keeps it open. max_frame_size can't be set below the 16,384-byte protocol minimum, and no setting moves the check earlier.

Proof of concept

1. Build an HTTP/2 frame header whose 24-bit length field declares 1,000,000 bytes, above the default max_frame_size of 16,384.
2. Pass the header followed by 16,384 and then 512,000 payload bytes to Mint.HTTP2.Frame.decode_next/2 with a limit of 16,384. Each call returns :more, which makes Mint.HTTP2 keep the bytes in conn.buffer.
3. Pass the header with the complete 1,000,000-byte payload. Only this call returns {:error, :payload_too_big}.

Impact

A malicious or compromised HTTP/2 server can make a Mint client keep up to about 16 MiB per connection buffered, and keep it there while the connection stays open. Clients that hold many HTTP/2 connections to attacker-influenced origins, such as webhook senders, crawlers and proxies, can run out of memory.

Workarounds

Connect to untrusted origins over HTTP/1 only, with protocols: [:http1] in Mint.HTTP.connect/4, which never runs the HTTP/2 frame decoder. Finch and Req pools use HTTP/1 only unless :http2 is added to their protocols option.