The Standard

Summary

In LiquidationPool, pendingStakes & holders array can be packed to gas grief and cause DoS for the pool and the runLiquidation function.

Vulnerability Details

Every time a new user stake in the pool, a new PendingStake struct is pushed to the pendingStakes array, and a new holder is added to the holders array:

The problem arises as functions distributeFees() and consolidatePendingStakes() iterate through those arrays, leading to increased gas costs with each iteration.

An attacker can exploit this by spamming the pool with multiple accounts, each staking small amounts, causing the arrays to grow excessively. This creates almost empty pending stakes, resulting in an Out of Gas (OOG) error when functions iterate through the arrays. Consequently, the runLiquidation() function becomes prohibitively expensive, potentially causing a revert due to exceeding the gas limit.

Making runLiquidation() so expensive to call and it may revert due to exceeding the block size gas limit.

Impact

The LiquidationPool contract is vulnerable to DoS attacks, where an attacker can use multiple accounts to stake small amounts, causing an Out of Gas error. This results in:

• The locking of user and liquidation funds within the contract.

• Critical functions like runLiquidation() will throw due to exceeding the block's gas limit.

Tools Used

Manual review

Recommendations

Consider enforcing a minimum stake amount a maximum array length for both holders and pendingStakes arrays in LiquidationPool to prevent such attacks.