sherlock-audit / 2023-06-symmetrical-judging

5 stars 4 forks source link

simon135 - since their is no check in openPosition for partyA pendingQuotes PartyA can get around the check for pendingPositions limits #332

Closed sherlock-admin closed 1 year ago

sherlock-admin commented 1 year ago

simon135

high

since their is no check in openPosition for partyA pendingQuotes PartyA can get around the check for pendingPositions limits

Summary

Dos can happen since the inside(after sendQuote) part of quote dosnt check the pending limit for PartyA

Vulnerability Detail

Here is an example but it just depends on the pending Positions limit

  1. the user has 14 pendingPositions and the limit is 15 so when 15 happens it should revert but it's not checked in this function so we can open more past the pending limit
  2. PartyB Takes 14 pending positions in locked Quote and then takes a partial position in OpenPosition causing the pendingQuotePartyA to increase by 1 and since there is no check after sendQuote for PartyPending Positions it can cause huge dos like making 14 pending/partial positions it making 28 pending positions now this will cause more dos and break in the invariant bigger ex: if 100 limit and so PartA makes 99 positions which turns into 1000 partial positions per pending position which turns into 99,000 pending which can cause dos in the system for all actors in quotes and when getting liquidated the pending positions for the loop might be dosed which can cause out-of-gas/reverts

    Impact

    gas griefing more than the protocol allows and gets over the invariant that limit is the most amount of pending that PartyA can have

    Code Snippet

    
        else {
            currentId = ++quoteLayout.lastId;
            QuoteStatus newStatus;
            if (quote.quoteStatus == QuoteStatus.CANCEL_PENDING) {
                newStatus = QuoteStatus.CANCELED;
            } else {
                newStatus = QuoteStatus.PENDING;
                quoteLayout.partyAPendingQuotes[quote.partyA].push(currentId);
            }

https://github.com/sherlock-audit/2023-06-symmetrical/blob/6d2b64b6732fcfbd07c8217897dd233dbb6cd1f5/symmio-core/contracts/facets/PartyB/PartyBFacetImpl.sol#L169C1-L177C14
## Tool used

Manual Review

## Recommendation
add a check for limit in pendingQuote because PartyA and PartyB can come together and cause dos in the system for the liquidator/bots or PartyB can do this and cause dos in the system

Duplicate of #301