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
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
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
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
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
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/revertsImpact
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