---

id: 476e0fbb-25b5-4051-92ae-8e38a1fef02e title: 'serve: unbounded thread-per-connection + 500ms ack sleep = trivial availability DoS' state: closed labels:

• security assignees: [] milestone: null created: 2026-10-27T14:53:46.365269127Z updated: 2026-10-27T15:48:00.976093000Z

---

hu13 serve is thread-per-connection with no cap, and every inbox response sleeps 500 ms.

Verified:

before: 1 thread
$ python3 open 300 idle sockets sending "GET / HTTP/1.1\r\nHost: x\r\n" (no terminator)
during: 301 threads   VmRSS 11.8 MB

Those sockets cost nothing per connection and can be kept alive indefinitely (a byte every < read timeout). ~10-30k cheap sockets exhaust the thread/pid limit or memory, and the server stops accepting.

Amplifiers:

• inbox handler always sleep(ACK_DELAY_MS) (500 ms) before answering, on every path including 400/403/429 — a rejected POST holds a thread for half a second
• settle() will additionally read up to 256 KiB from a lying Content-Length before answering
• no accept-backlog tuning, no per-IP connection limit, no global connection cap

Related, same class but separate resource: #63 (git upload-pack with no timeout/cap).

Fix direction:

• cap concurrent connections (e.g. semaphore of 64-256) and answer 503 immediately when exhausted
• keep the fixed ack delay for semantic uniformity, but do not let it pin a thread: either keep it (with the cap above) or use a small timer wheel; the cap is the simpler fix
• optionally lower POST_READ_TIMEOUT_SECS and require the head within a shorter window than the body

Acceptance:

• N idle sockets beyond the cap get refused/closed, not thread-per-connection
• process thread count has a documented upper bound
• a test/bench opens >cap sockets and asserts the server still answers /