Core Contracts

Summary

The liquidateBorrower() function which is used to liquidate an undercollaterized borrower position have a faulty logic

Vulnerability Details

Firstly, this function gets the user's debt and scaledUserDebt from the lendingPool. It then preceed to make some check on the balance of crvUsdBalance in the stabiltyPool and simply revert the transaction if users bad debt position(scaledUserDebt) is greater than the crvUSDBalance in the contract.

According to the Docs, it states that "While the debt accruing is compounding, the liquidity rate is linear. As such, the transferAccruedDust exists so those funds can be sent to the stabilityPool for liquidation events". This implies that crsUSDToken find it's way into the stability pool through the transferAccruedDust().
Upon further inspection, it was observed that the accrued token dust which is the excess of the underlying token(crvUSDToken) that is not tied to rToken which could either return 0 or a dust amount depending will not be sufficient to solve a undercollarized position.
If the dust amount is zero due to borrowers not paying extra amount while repaying debt in the _repay() function, the liquidateBorrower() will always revert this liquidate transaction which will result to problematic implementation of this protocol

Impact

This can result to a huge bad debt position for the protocol as the stability pool will most often not have enough liquidity to close a borrower position and the liquidateBorrower() will keep on reverting the transaction for a really long time especially during earlier stage of this protocol creation.

Tools Used

Manual review

Recommendations

Rather than depending on the accrued dust for liquidation funding, introduce an extra dependency in the lliquidation process