The Standard

Summary

Not having a cap/upper limit on holder's array while adding unique holders using addUniqueHolder, might cause distrbuteFees & distributeAssets to run out of gas and revert , leading to holders not getting their rewards/assets.

Vulnerability Details

LiquidationPool::increasePosition() is meant to increase position of who is already a holder or adding a new unique holder by using LiquidationPool::addUniqueHolder()

Now while distribution of fees and assets through LiquidationPool::distributeFees() & LiquidationPool::distributeAssets(), holder's array is being iterated in order to distribute to all holders their respective rewards/assets.

An attacker could exploit this by sending small amounts of TST tokens / sEURO ("dust") from many different addresses, which would then be added as unique holders. This could artificially inflate the holders array, making the distributeAssets function potentially run out of gas when trying to distribute assets to a large number of holders.

Similar can happen for distributeFees function.

Impact

This would lead to holders not receiving their rewards/assets after liquidation process which they were meant to get for staking.

Likelihood of this scenario is very less, but if happens, does have a great impact, hence issued as MEDIUM risk.

Tools Used

Manual reviewing of codebase

Recommendations

To mitigate this, following recommendations can be implemented

1. A cap could be set on the number of holders OR

2. The distributeAssets & distributeFees function could implement a paging mechanism where it processes a set number of holders at a time. OR

3. There should be a minimum amount of TST / sEURO values that should be deposited while staking while using increasePosition in order to prevent from dust deposition.