What the developer wrote
Authored by tobtoht
Merge pull request #11144
02411be protocol: flush rejected block spans from disconnected peers (selsta)
ACKs: jpk68, plowsof, j-berman
What changed, and why it matters
This Monero update makes the network layer clean up leftover block download records when a peer connection fails or is rejected. Previously, rejected or disconnected peers could leave stale block spans in a queue, which might cause the node to skip fetching those blocks from other peers and potentially stall synchronization. The fix flushes those stale spans so the node can re-request the blocks elsewhere.
Treat as a routine reliability/DoS-hardening fix. Apply the patch and monitor for any regressions in block synchronization. No immediate incident response is indicated by the diff alone.
Security signals we found
Denial-of-service resistance: stale block spans from malicious or faulty peers could prevent a node from obtaining valid blocks
State cleanup on peer disconnection/rejection
No authentication or memory-safety bug evident in diff
Evidence from the diff
The patch adds m_block_queue.flush_spans(…) calls in two places in cryptonote_protocol_handler.inl: (1) when prepare_handle_incoming_blocks fails for blocks received from a peer, and (2) inside drop_connection when a specific peer is being dropped. This ensures block spans associated with a disconnected or rejected peer are removed from the block queue, rather than remaining marked as requested/in-flight. The change is small and defensive, aimed at preventing synchronization stalls caused by stale span state.
Changed components
src/cryptonote_protocol/cryptonote_protocol_handler.inlMonero P2P block synchronization queue (m_block_queue)Peer connection drop logicInspect captured patch +2 / −0
### src/cryptonote_protocol/cryptonote_protocol_handler.inl
@@ -1500,6 +1500,7 @@ namespace cryptonote
if (!m_core.prepare_handle_incoming_blocks(blocks, pblocks))
{
LOG_ERROR_CCONTEXT("Failure in prepare_handle_incoming_blocks");
+ m_block_queue.flush_spans(span_connection_id, true);
drop_connections(span_origin);
return 1;
}
@@ -2862,6 +2863,7 @@ skip:
template<class t_core>
void t_cryptonote_protocol_handler<t_core>::drop_connection(const boost::uuids::uuid& id)
{
+ m_block_queue.flush_spans(id, true);
m_p2p->for_connection(id, [this](cryptonote_connection_context& context, nodetool::peerid_type peer_id, uint32_t f)->bool{
// This _could be_ outside of strand, so careful on actions
drop_connection(context, true, false);Why this scored 34/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.