From 9563beea569fda8761fcf919a297ef9c31a99b13 Mon Sep 17 00:00:00 2001 From: Kim De Mey Date: Fri, 20 Oct 2023 18:03:20 +0200 Subject: [PATCH] Don't send the processed bitlist if contentQueue is full (#1835) This would lead to sending an AcceptMessage with a zeroed out connection id but still potentially bits set in the bitlist. Requesting nodes could try to open up an uTP connection that would never be accepted on the responder side. --- fluffy/network/wire/portal_protocol.nim | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/fluffy/network/wire/portal_protocol.nim b/fluffy/network/wire/portal_protocol.nim index 0b82a7691..b928fa7a7 100644 --- a/fluffy/network/wire/portal_protocol.nim +++ b/fluffy/network/wire/portal_protocol.nim @@ -350,6 +350,14 @@ proc handleFindContent( encodeMessage(ContentMessage(contentMessageType: enrsType, enrs: enrs)) proc handleOffer(p: PortalProtocol, o: OfferMessage, srcId: NodeId): seq[byte] = + # Early return when our contentQueue is full. This means there is a backlog + # of content to process and potentially gossip around. Don't accept more + # data in this case. + if p.stream.contentQueue.full(): + return encodeMessage(AcceptMessage( + connectionId: Bytes2([byte 0x00, 0x00]), + contentKeys: ContentKeysBitList.init(o.contentKeys.len))) + var contentKeysBitList = ContentKeysBitList.init(o.contentKeys.len) var contentKeys = ContentKeysList.init(@[]) # TODO: Do we need some protection against a peer offering lots (64x) of @@ -370,7 +378,7 @@ proc handleOffer(p: PortalProtocol, o: OfferMessage, srcId: NodeId): seq[byte] = return @[] let connectionId = - if contentKeysBitList.countOnes() != 0 and not p.stream.contentQueue.full(): + if contentKeysBitList.countOnes() != 0: p.stream.addContentOffer(srcId, contentKeys) else: # When the node does not accept any of the content offered, reply with an