sherlock-audit / 2023-03-taurus-judging

4 stars 0 forks source link

0x52 - Potential decimal mismatches in BaseVault calculations #177

Closed sherlock-admin closed 1 year ago

sherlock-admin commented 1 year ago

0x52

high

Potential decimal mismatches in BaseVault calculations

Summary

Decimals may mismatch when calculating maxLiquidation and other collateral values

Vulnerability Detail

BaseVault.sol#L240-L261

function _getMaxLiquidation(
    uint256 _collateral,
    uint256 _debt,
    uint256 _price,
    uint8 _decimals,
    uint256 _liquidationDiscount
) internal pure returns (uint256 maxRepay) {
    // Formula to find the liquidation amount is as follows
    // [(collateral * price) - (liqDiscount * liqAmount)] / (debt - liqAmount) = max liq ratio
    // Therefore
    // liqAmount = [(max liq ratio * debt) - (collateral * price)] / (max liq ratio - liqDiscount)
    maxRepay =
        ((MAX_LIQ_COLL_RATIO * _debt) - ((_collateral * _price * Constants.PRECISION) / (10 ** _decimals))) /
        (MAX_LIQ_COLL_RATIO - _liquidationDiscount); <- @audit potential decimal mismatch if debt dp != coll dp

    // Liquidators cannot repay more than the account's debt
    if (maxRepay > _debt) {
        maxRepay = _debt;
    }

    return maxRepay;
}

_getMaxLiquidation compares _debt directly to _collateral. If debt and collateral don't share the same number of decimals then the math won't be correct and it will return a maxRepay value that is too high.

Impact

Low decimal tokens won't be able to borrow enough and high decimal tokens will be able to borrow too much

Code Snippet

BaseVault.sol#L240-L261

Tool used

Manual Review

Recommendation

Normalized collateral to 18 decimals

Duplicate of #35