Properly handle oversized ledger data replies

This commit is contained in:
Nik Bougalis
2021-11-10 21:31:50 -08:00
parent 0c47cfad6f
commit ef60ac8348
2 changed files with 13 additions and 11 deletions

View File

@@ -1853,13 +1853,6 @@ PeerImp::onMessage(std::shared_ptr<protocol::TMLedgerData> const& m)
if (m->type() < protocol::liBASE || m->type() > protocol::liTS_CANDIDATE)
return badData("Invalid ledger info type");
// Verify ledger nodes
if (m->nodes_size() <= 0 || m->nodes_size() > Tuning::maxReplyNodes)
{
return badData(
"Invalid Ledger/TXset nodes " + std::to_string(m->nodes_size()));
}
// Verify reply error
if (m->has_error() &&
(m->error() < protocol::reNO_LEDGER ||
@@ -1868,6 +1861,13 @@ PeerImp::onMessage(std::shared_ptr<protocol::TMLedgerData> const& m)
return badData("Invalid reply error");
}
// Verify ledger nodes.
if (m->nodes_size() <= 0 || m->nodes_size() > Tuning::hardMaxReplyNodes)
{
return badData(
"Invalid Ledger/TXset nodes " + std::to_string(m->nodes_size()));
}
// If there is a request cookie, attempt to relay the message
if (m->has_requestcookie())
{
@@ -3503,7 +3503,7 @@ PeerImp::processLedgerRequest(std::shared_ptr<protocol::TMGetLedger> const& m)
std::vector<Blob> rawNodes;
for (int i = 0; i < m->nodeids_size() &&
ledgerData.nodes_size() < Tuning::maxReplyNodes;
ledgerData.nodes_size() < Tuning::softMaxReplyNodes;
++i)
{
auto const shaMapNodeId{deserializeSHAMapNodeID(m->nodeids(i))};

View File

@@ -35,9 +35,11 @@ enum {
consider it diverged */
divergedLedgerLimit = 128,
/** The maximum number of ledger entries in a single
reply */
maxReplyNodes = 8192,
/** The soft cap on the number of ledger entries in a single reply. */
softMaxReplyNodes = 8192,
/** The hard cap on the number of ledger entries in a single reply. */
hardMaxReplyNodes = 12288,
/** How many timer intervals a sendq has to stay large before we disconnect
*/