Lines of code

https://github.com/code-423n4/2023-05-venus/blob/main/contracts/Comptroller.sol#L1099-L1109

Vulnerability details

Impact

File: Comptroller.sol
1099         uint256 exchangeRateMantissa = VToken(vTokenCollateral).exchangeRateStored(); // Note: reverts on error
1100         uint256 seizeTokens;
1101         Exp memory numerator;
1102         Exp memory denominator;
1103         Exp memory ratio;
1104
1105         numerator = mul_(Exp({ mantissa: liquidationIncentiveMantissa }), Exp({ mantissa: priceBorrowedMantissa }));
1106         denominator = mul_(Exp({ mantissa: priceCollateralMantissa }), Exp({ mantissa: exchangeRateMantissa }));
1107         ratio = div_(numerator, denominator);
1108
1109         seizeTokens = mul_ScalarTruncate(ratio, actualRepayAmount);

seizeTokens = seizeAmount / exchangeRate
    = actualRepayBorrowedUTokenAmount * (liquidationIncentive * priceBorrowed) / (priceCollateral * exchangeRate)
    = actualRepayBorrowedUTokenAmount * (liquidationIncentive * priceBorrowed) / (priceCollateral * CollateralUTokenBalance / CollateralVTokenBalance)
    = actualRepayBorrowedUTokenAmount * liquidationIncentive * priceBorrowed * CollateralVTokenBalance / (priceCollateral * CollateralUTokenBalance)

The result is expected only if the precision of vTokenBorrowed and vTokenCollateral are the same, but the precision of the two can be different

Proof of Concept

Tools Used

manual

Recommended Mitigation Steps

It is recommended to consider scenarios with different precision

Assessed type

Decimal

code-423n4 / 2023-05-venus-findings

`Comptroller.sol#liquidateCalculateSeizeTokens` assumes the same precision for `vTokenBorrowed` and `vTokenCollateral` #450