AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Moderate 62 Bitcoin

http: prevent race condition between worker thread and I/O thread

Public commit record

What the developer wrote

Authored by Matthew Zipkin

73/100 · Adequate
http: prevent race condition between worker thread and I/O thread

This prevents a losing race condition that could prevent the server
from reading requests from an HTTP client.

A connected socket can either be written to or read from based on the
result of GenerateWaitSockets(). That method checks the HTTPRemoteClient
flag m_send_ready. If it's `true` the implication is that there is
data in the client's send buffer ready to go. Once that data is sent
and the buffer is empty, MaybeSendBytesFromBuffer() sets it `false` again.

The sad case was when a worker thread calling WriteReply() adds
data to the send buffer, but before it sets m_send_ready to `true`,
the I/O thread sends that data and empties the buffer. With the
buffer unexpectedly empty, WriteReply() sets m_send_ready to `true`.

The effect of this is that the socket will stay in "write" mode
with nothing to write. With nothing to write, MaybeSendBytesFromBuffer()
never sets it back to `false` and the socket is stuck forever.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a subtle timing bug in Bitcoin Core's built-in HTTP server. Under a specific race between a worker thread preparing a response and the I/O thread sending data, a connection could get permanently stuck waiting to write even though there was nothing left to send. Once stuck, the server would stop reading new requests from that client, effectively hanging the connection. The fix moves the 'ready to send' flag update under the same lock as the send buffer and protects reads of that flag with a separate lock to avoid deadlocks.

Recommended action

Treat as a reliability/DoS-hardening fix. Backport to maintained branches if HTTP RPC/REST interface is exposed. No immediate emergency response required because exploitation appears probabilistic and only affects an existing connection, but node operators serving RPC should upgrade in due course.

Security signals we found

01

Race condition between worker thread and I/O thread on shared state

02

Potential denial-of-service via hung HTTP connection

03

Lock ordering comment to prevent deadlock regression

04

Change from atomic bool to mutex-guarded bool indicating synchronization semantics changed

Risk score

Why this scored 62/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 10/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.