Hackney: Per-chunk timeout with unbounded body accumulation enables slow-drip OOM

Summary

hackney_h3:await_response_loop/6 in src/hackney_h3.erl accumulates the HTTP/3 response body in memory without any size cap. The after Timeout clause is a per-message inactivity timer, not a wall-clock deadline: every received stream_data chunk, housekeeping select message, or settings frame resets it. A malicious HTTP/3 server that drips one small chunk every Timeout - 1 ms with Fin = false and never terminates the stream keeps the loop alive indefinitely while the accumulation buffer grows without bound, eventually exhausting the BEAM process heap.

Details

In src/hackney_h3.erl, await_response_loop/6 (line 430) builds the body with:

NewBody = <<AccBody/binary, Data/binary>>

There is no max_body check and no monotonic deadline. The after Timeout clause at line 463 is restarted on each loop iteration. A server that ensures at least one message arrives within Timeout ms indefinitely (one small chunk per interval is sufficient) prevents the timeout from firing while AccBody grows linearly. The same module's wait_connected/3 (lines 388-389) shows the correct pattern: track an absolute start time and pass a shrinking Remaining budget into each receive. This loop does not.

Configurations

Only the HTTP/3 transport is affected. Applications using the default TCP/TLS hackney transport are not vulnerable. The vulnerability requires using hackney_h3 directly or passing {transport, h3} to hackney:request/5.

PoC

1. Stand up an HTTP/3 server that responds with 200 OK headers (Fin = false), then emits a small stream_data chunk every Timeout - margin ms with Fin = false indefinitely.
2. Issue hackney:request(get, Url, [], <<>>, [{transport, h3}]) against it.
3. Watch the client process heap grow monotonically. The configured timeout never fires; the process is eventually killed by or the OS OOM killer.