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

Merge bitcoin/bitcoin#36123: http: throttle per-connection reads while a request is in flight

Public commit record

What the developer wrote

Authored by merge-script

86/100 · Strong
Merge bitcoin/bitcoin#36123: http: throttle per-connection reads while a request is in flight

3d1004cb9b8f27bd328d95b4c7524e878c296d61 http: throttle per-connection reads while a request is in flight (Matthew Zipkin)

Pull request description:

This patches a memory exhaustion scenario found while auditing the new http server with kimi-k3. A shallow version of this scenario was addressed in #35735 (See https://github.com/bitcoin/bitcoin/pull/35735#discussion_r3720177656 and https://github.com/bitcoin/bitcoin/pull/35735#issuecomment-5217000202) but a OOM vector still remained.

On master when the sever is busy handling a request from a client, it will still read data from that client and "queue up" the next request. In #35735 we handled the scenario where that additional incoming data was an invalid HTTP request by not attempting to parse the data. However, we didn't add a size limit.

A misbehaving client could block its request queue with something like `waitforblock` and then flood the server with nonsense data without any limit.

The solution in this patch is to not even read from the socket at all if we are busy with a request. Similar to the intent of #35735, the kernel will buffer incoming data until backpressure kicks in and the TCP window drops to 0.

If unaddressed, the attack vector is still limited to authenticated clients: unauthenticated REST requests don't block for very long, so the server *should* be able to drain the receive buffer.

ACKs for top commit:
jeanpablojp:
tACK 3d1004cb9b8f27bd328d95b4c7524e878c296d61
frankomosh:
ACK 3d1004cb9b8f27bd328d95b4c7524e878c296d61
hodlinator:
ACK 3d1004cb9b8f27bd328d95b4c7524e878c296d61
winterrdog:
tACK 3d1004cb9b8f27bd328d95b4c7524e878c296d61
sedited:
ACK 3d1004cb9b8f27bd328d95b4c7524e878c296d61

Tree-SHA512: 56f7678a9ab6789aa542c1f252df0b6ccf9137cb426ff915a0a3fe8285200fdb62b7a47c476ed8617c3592e7a7eac18158cd8c0dac309cdcf4e5fd887e016209
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This update fixes a memory exhaustion bug in Bitcoin Core's built-in web server. An authenticated user could keep one slow request open and then flood the server with endless extra data, causing it to run out of memory. The fix tells the server to stop reading from that connection while it is still busy with the first request, letting the operating system's network buffers absorb the flood instead.

Recommended action

Apply the merge commit. The change is defensive and low-risk: it only suppresses socket reads when buffered pipelined data already exists while a request is in flight. Operators running RPC servers should upgrade, as the issue is exploitable by any authenticated RPC user.

Security signals we found

01

Memory exhaustion / OOM vector in HTTP server

02

Unbounded receive buffer growth on authenticated connection

03

Per-connection read throttling via event-loop change

04

TCP backpressure used as mitigation

05

Functional regression test added for the vulnerability scenario

Risk score

Why this scored 70/100

Our methodology →
Potential impact 22/30
Exploitability 14/25
Stealth signal 10/15
Affected reach 10/15
Confidence 9/10
Evidence quality 5/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.