The Standard

Summary

In the liquidation pool, multiple function calls to increase a position could cause other functions in the contract to be out of service permanently.

Vulnerability Details

In LiquidationPool.sol the function call increasePosition() could be called multiple times by a malicious actor with values of 1 for either token, this turn will call the line:

pendingStakes.push(PendingStake(msg.sender, block.timestamp, _tstVal, _eurosVal));

as the pendingStakes array gets larger it will cost more gas to call the function consolidatePendingStakes(), since each array index is only removed after a 24 hour period. Which means the protocol could receive more transactions to increase a position from other users within this period. After a certain amount of calls to increasePosition() cost of calling the functions increasePosition(), decreasePosition() and distributeAssets() will exceed the block gas limit.

The main cause is the unbounded for loop

for (int256 i = 0; uint256(i) < pendingStakes.length; i++) {...}

in consolidatePendingStakes() and the unbounded for loop

function deletePendingStake(uint256 _i) private {...}

in deletePendingStake().

Impact

DOS to the functions increasePosition(), decreasePosition() and distributeAssets() and as a consequence locked user rewards.

Tools Used

Manual Review

Recommendations

I would recommend that the time delay be removed for increasing positions as this will prevent a pileup of unprocessed pending stakes. In the function deletePendingStake(), I would recommend that index to be deleted is searched for and once found, the last index is moved to that position and then the array is popped.