Skip to content

[pull] master from bitcoin:master - #1835

Merged
pull[bot] merged 2 commits into
All-Blockchains:masterfrom
bitcoin:master
Sep 5, 2026
Merged

[pull] master from bitcoin:master#1835
pull[bot] merged 2 commits into
All-Blockchains:masterfrom
bitcoin:master

Conversation

@pull

@pullpullBot commented Sep 5, 2026

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

pinheadmzand others added 2 commits September 1, 2026 15:56
A client streaming pipelined requests into a busy connection
(or any connection whose replies are slower than the sender) could grow
server memory without limit, up to remote OOM.
Stop selecting RecvEvent for clients whose request is being processed;
pipelined data then backs up in the kernel socket buffer, applying TCP
backpressure to the sender. One request per connection is in flight
at a time.
Functional test streams pipelined submitblock requests into a connection
blocked on waitforblockheight. Unpatched builds continue draining the
socket buffer indefinitely, patched builds will stall.
…in flight
3d1004c 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 #35735 (comment) and #35735 (comment)) 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 3d1004c
frankomosh:
ACK 3d1004c
hodlinator:
ACK 3d1004c
winterrdog:
tACK 3d1004c
sedited:
ACK 3d1004c
Tree-SHA512: 56f7678a9ab6789aa542c1f252df0b6ccf9137cb426ff915a0a3fe8285200fdb62b7a47c476ed8617c3592e7a7eac18158cd8c0dac309cdcf4e5fd887e016209
@pullpullBot locked and limited conversation to collaborators Sep 5, 2026
@pullpullBot added the ⤵️ pull label Sep 5, 2026
@pull
pullBot merged commit f0c839a into All-Blockchains:masterSep 5, 2026
0 of 25 checks passed
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@pinheadmz@sedited