Badger eBTC Audit + Certora Formal Verification Competition - rvierdiiev's results

Lines of code

https://github.com/code-423n4/2023-10-badger/blob/main/packages/contracts/contracts/LiquidationLibrary.sol#L679-L727

Vulnerability details

Proof of Concept

LiquidationLibrary.batchLiquidateCdps is called from CDPManager in order to liquidate list of cdps. Depending if system is currently in recovery mode liquidations will be done inside _getTotalFromBatchLiquidate_RecoveryMode or _getTotalsFromBatchLiquidate_NormalMode function.

After that _finalizeLiquidation function will be called, which will then do several important system updates, token transfer and what is important for this report bad debt redistribution. In case if new bad debt occurs in the system, then this debt amount is redistributed to all stakers that are still in the system.

Now, lets check how liquidations occur by _getTotalsFromBatchLiquidate_NormalMode function. This function loops through all cpds one by one. It fetches ICR for them using getSyncedICR function. This function will calculate ICR not on stored debt and coll of cdp, but it will update this values, according to new fee rate(which means that coll will be reduced) and redistribute rate(which means that debt will increase, if rate is bigger than stored for cdp).

This is how it will be done for redistribution. https://github.com/code-423n4/2023-10-badger/blob/main/packages/contracts/contracts/CdpManagerStorage.sol#L864-L868

    function getSyncedICR(bytes32 _cdpId, uint256 _price) public view returns (uint256) {
        uint256 _debt = getSyncedCdpDebt(_cdpId);
        uint256 _collShare = getSyncedCdpCollShares(_cdpId);
        return _calculateCR(_collShare, _debt, _price);
    }

Then getSyncedCdpDebt is called, which calls _getSyncedCdpDebtAndRedistribution function. https://github.com/code-423n4/2023-10-badger/blob/main/packages/contracts/contracts/CdpManagerStorage.sol#L822-L833

    function _getSyncedCdpDebtAndRedistribution(
        bytes32 _cdpId
    ) internal view returns (uint256, uint256, uint256) {
        (uint256 pendingDebtRedistributed, uint256 _debtIndexDelta) = _getPendingRedistributedDebt(
            _cdpId
        );
        uint256 _newDebt = Cdps[_cdpId].debt;
        if (pendingDebtRedistributed > 0) {
            _newDebt = _newDebt + pendingDebtRedistributed;
        }
        return (_newDebt, pendingDebtRedistributed, _debtIndexDelta);
    }

So debt of cdp will be increased pendingDebtRedistributed, which depends on redistribution rate of position and current redistribution rate.

Later, for each cdp _getLiquidationValuesNormalMode function will be called, which will actually do the liquidation. It will call _liquidateIndividualCdpSetupCDPInNormalMode function. Inside of it _calculateFullLiquidationSurplusAndCap function is called and it's purpose is to calculate shares that liquidator and cdp owner should receive and bad debt to redistribute.

So after liquidation has finished, then _addLiquidationValuesToTotals function is called, which will add values from previous liquidation(including redistribution debt) to the total accumulator.

So finally, i can explain the problem. In case if in batch there is cdp, that will create bad debt after liquidation, then this debt will not be redistributed to all next liquidations, as redistribution index is not updated after each liquidation. And as result, next liquidations will have incorrect debt value, which means that smaller amount of debt will be liquidated and bigger amount of coll will be received by cdp owner. And also all else users in the system will have to cover that delta debt that was not redistributed to next liquidations.

Impact

Bad debt is distributed incorrectly.

Tools Used

VsCode

Recommended Mitigation Steps

You need to redistribute bad debt after each liquidation in the batch(in case if bad debt occured).

Assessed type

Error