LLM disclosure: Found with the help of Claude Opus 4.6, fix, test, description, and commit messages written by me.
This fixes a low-severity issue where a misbehaving Tor control daemon can cause
bitcoind to OOM by sending continuation lines without sending 250 OK or
similar.
This issue is not that serious because if your tor control daemon is malicious you are already in all kinds of trouble, but as a matter of robustness this should be fixed.
The fix is to prevent the TorControlConnection::m_message buffer from growing
without bound by by limiting the number of lines handled by TorControlConnection::ProcessBuffer()
to MAX_LINE_COUNT = 1000. Now the most memory that can be occupied by
m_message is on the order of MAX_LINE_LENGTH * MAX_LINE_COUNT= 100MB
Although this is not compliant with the Tor control protocol in general,
where commands like GETINFO ns/all will likely return thousands of
lines, it is more than sufficient for handling the replies from the
commands that are used by a node:
<details>
<summary>
Tor control commands used by Bitcoin Core
</summary>
AUTHENTICATE: 1 line:
The server responds with 250 OK on success or 515 Bad
authentication if the authentication cookie is incorrect. Tor closes
the connection on an authentication failure.
https://spec.torproject.org/control-spec/commands.html#authenticate
GETINFO net/listener/socks: 2 lines
A quoted, space-separated list of the locations where Tor is
listening...
https://spec.torproject.org/control-spec/commands.html#getinfo
AUTHCHALLENGE SAFECOOKIE: 1 line
If the server accepts the command, the server reply format is:
```
"250 AUTHCHALLENGE" SP "SERVERHASH=" ServerHash SP "SERVERNONCE="
ServerNonce CRLF
```https://spec.torproject.org/control-spec/commands.html#authenticate
PROTOCOLINFO: 4-5 lines
The server reply format is:
```
250-PROTOCOLINFO" SP PIVERSION CRLF \*InfoLine "250 OK" CRLF
InfoLine = AuthLine / VersionLine / OtherLine
```(https://spec.torproject.org/control-spec/commands.html#protocolinfo)
ADD_ONION: 2-3 lines for Bitcoin Core's tor control client.
The server reply format is:
```
"250-ServiceID=" ServiceID CRLF
["250-PrivateKey=" KeyType ":" KeyBlob CRLF]
*("250-ClientAuth=" ClientName ":" ClientBlob CRLF)
"250 OK" CRLF
```
...
The server response will only include a private key if the server
was requested to generate a new keypair
...
If client authorization is enabled using the “BasicAuth” flag (which
is v2 only), the service will not be accessible to clients without
valid authorization data (configured with the “HidServAuth” option).
The list of authorized clients is specified with one or more
“ClientAuth” parameters. If “ClientBlob” is not specified for a
client, a new credential will be randomly generated and returned."https://spec.torproject.org/control-spec/commands.html#add_onion
We don't set the BasicAuth flag, so the response will not include any
ClientAuthLines.
</details>
Reproduce
To reproduce this issue, the following script or similar can be used as the misbehaving Tor control daemon:
#!/usr/bin/env python3
"""
A fake Tor control service that never finishes its reply. Sends unlimited
continuation lines ("250-...") without ever sending the final "250 ...".
Each line accumulates in m_message.lines with no cap. Bitcoind OOMs.
"""
import socket
import time
PORT = 19191
server = socket.create_server(("127.0.0.1", PORT))
conn, _ = server.accept()
conn.recv(4096) # Receive PROTOCOLINFO
time_start = time.time()
try:
while True:
conn.sendall(b"250-Ceaseless\r\n" * 10000)
except (BrokenPipeError, ConnectionResetError):
elapsed = time.time() - time_start
print(f"Node disconnected after {elapsed:.2f}s")
🟡¡This will OOM, run in a container, VM, or some sandbox with memory limits!🟡
Start a node with -torcontrol=127.0.0.1=19191.
E.g. with systemd:
systemd-run --user --scope -p MemoryMax=2G -p MemorySwapMax=0 bitcoind -regtest -torcontrol=127.0.0.1:19191
