Venus Protocol Isolated Pools - mussucal's results

Lines of code

https://github.com/code-423n4/2023-05-venus/blob/8be784ed9752b80e6f1b8b781e2e6251748d0d7e/contracts/VToken.sol#L1026-L1032 https://github.com/code-423n4/2023-05-venus/blob/8be784ed9752b80e6f1b8b781e2e6251748d0d7e/contracts/Comptroller.sol#L449-L454 https://github.com/code-423n4/2023-05-venus/blob/8be784ed9752b80e6f1b8b781e2e6251748d0d7e/contracts/Comptroller.sol#L469-L472

Vulnerability details

Impact

In preLiquidateHook(), TooMuchRepay() reverts when it should not and may cause DoS.

Proof of Concept

File: VToken.sol Functions: liquidateBorrow(), _liquidateBorrow(), _liquidateBorrowFresh() It is not possible to know the exact repayAmount to be passed at the start in liquidateBorrow(). Hence, to completely liquidate an amount sufficiently greater than borrow amount is desired. Down the line, preLiquidateHook() is called with repayAmount as parameter. Inside the hook checks are there like (repayAmount > borrows) and (repayAmount > maxClose) which reverts with TooMuchRepay() each time.

Tools Used

Manual review.

Recommended Mitigation Steps

1. The actualRepayamount is calculated by calling _repayBorrowFresh().
2. Call to hook should be after actualRepayAmount calculation.
3. In preLiquidateHook() the actualRepayAmount should be passed as parameter rather than repayAmount.

Assessed type

Other