No per-message receive timeout allows slow loris / hang DoS #116
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
receive_n_data()loops until all bytes arrive or the connection closes. There is no per-message timeout beyond the socket-level SO_RCVTIMEO (30s). An attacker can send partial data byte-by-byte and stall indefinitely, tying up server processes.Location
src/shared/protocol.c:97-125 (receive_n_data)
How to trigger
Connect to the server and send one byte, then wait 29 seconds, then send another byte. The server will wait for the full message indefinitely within the 30s socket timeout window, but the connection can be kept alive for a very long time with slow trickle sends.
Suggested Fix
Add a per-message deadline (e.g., 60 seconds from the start of each
receive_n_datacall). Track elapsed time withclock_gettime(CLOCK_MONOTONIC)and abort the receive if the deadline is exceeded. Alternatively, reduce SO_RCVTIMEO to a lower value.Severity
medium
Category
security
Sub-Agent
security-screener (SC-5)
This issue was automatically generated by the issue-creator agent.
Fixed in PR #148 — merged into main on 2026-07-29. See #148