# [tor] control connection pre-auth DoS (infinite loop) with --enable-bufferevents

Tor control port with --enable-bufferevents enters infinite loop on input >1024 bytes with a linefeed past byte 1024, hanging the daemon pre-auth.

- Payout: hidden
- Severity: medium
- Program: Tor
- Found by: guido
- Disclosed: 2017-10-19
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/113424
- Library page: https://bugbountylibrary.com/r/h1%3A113424
- Tags: area:devices domain:network impact:dos kind:bounty platform:hackerone sev:medium tech:linux technique:chained technique:source-review vuln:dos

**Target:** Tor control port (ControlPort) line-fetch routine
**Root cause:** In connection_fetch_from_buf_line with bufferevents, the 'too long' branch returns -1 without updating *data_len to the required size, so the caller's realloc loop never grows the buffer and spins forever.
**Steps:**
1. Build tor with `./configure --enable-bufferevents && make -j4`
2. Start tor with `ControlPort 9999`
3. Send a line of 2000 'c' bytes followed by `\n` to port 9999 (e.g. `ncat localhost 9999 <poc`)
4. Tor hangs and must be killed with `kill -9`
**How found:** Code review of control.c line-fetch loop; noticed the bufferevent branch returns -1 without setting *data_len, unlike fetch_from_buf_line which sets it, breaking the realloc growth loop.
**Exploitation:** Any input >1024 bytes with a linefeed after byte 1024 triggers the loop. A malicious webpage can issue `<img src='http://localhost:9999/xxxx...'>` so a browser sends a long GET to the local control port, DoSing tor while the user browses.
**Escalation:** Cross-protocol: browser-driven request to localhost control port turns a local-only bug into a web-triggered DoS.
**Insight:** When two implementations of the same helper exist behind an #ifdef, diff their contract: the bufferevent variant failed to write back the required size that the caller's realloc loop depends on.