The Standard

Summary

The known issues state that they are aware that the holders's length is not checked, but they do not mention that pendingStakes could aswell (and even more easily) be inflated and cause a DoS for other users.

Vulnerability Details

The increasePosition() function that manages creation/increasing of user positions allows for the indefinite increase of the pendingStakes array, that gets iterated over on every call by consolidatePendingStakes(). The problem becomes even worse if you account for the fact that deletePendingStake() has the potential to be called for every single pending stake in consolidatePendingStakes(), meaning the loop will be iterated more than once.
A malicious user or a party of users could fill the pendingStakes with dummy stakes of 1 TST or 1 EUROs, creating an incredibly large array in combination with regular users' stakes. When all of these dummy stakes pass their pending period, on the next call to consolidatePendingStakes(), they would need to be deleted from the array. If we take N as the potentially large length of pendingStakes and and we have filled the array from the start, we could potentially have an above O(n^2) complexity, which almost certainly will cause the transaction to hit an OOG. If we reach a number of pending stakes that causes an OOG, all other other users would be DoSed aswell since every call to increase a position would try to consolidate the array and would fail, rendering the protocol insolvent.

Impact

DoS, Liquidation pool insolvency

Tools Used

Manual Review

Recommendations

Introduce a minimum amount of TST or EUROs a user has to deposit to his position to make the attack exponentially more difficult. Consider changing the way pending stakes are consolidated to avoid 1 user's transaction affecting all users. Could be done by some admin controlled method.