074.md

Powerful Honeysuckle Anteater

High

dCDS depositors won't be able to withdraw their funds, if a lot of liquidations ocured since their deposit

Summary

When calculating the amount of liquidation value to give to a dCDS depositor who is withdrawing, the protocol loops through all the liquidation indexes since the time of the deposit. This is dangerous because, if enough time passes, the loop could exceed the block gas limit, effectively making the depositor's funds inaccessible.

Root Cause

Code reference for the unbounded loop: CDSLib.sol#L639-L640

    function withdrawUser(...) public returns (CDSInterface.WithdrawResult memory) {
.......
            uint128 liquidationIndexAtDeposit = params.cdsDepositDetails.liquidationindex;
            if (params.omniChainData.noOfLiquidations >= liquidationIndexAtDeposit) {
//@audit-issue this does not have any limit, meaning that if enough liquidations are reached, users won't be able to withdraw their dCDS deposits.
@>>             for (uint128 i = (liquidationIndexAtDeposit + 1); i <= params.omniChainData.noOfLiquidations; i++) {
.......
                    }
               }

.......
            return CDSInterface.WithdrawResult(
                params.cdsDepositDetails,
                params.omniChainData,
                params.ethAmount,
                params.usdaToTransfer,
                params.optionFees,
                totalCdsDepositedAmount,
                totalCdsDepositedAmountWithOptionFees
            );
        }
    }

Attack Path

1. A user deposits stablecoins into the dCDS contract.
2. Time passes (minimum withdrawal delay is 30 days).
3. The user decides to withdraw. However, the number of liquidations that have occurred since their deposit is large enough to cause an Out-Of-Gas (OOG) exception.

Impact

Funds would be stuck as the gas cost of the transaction could exceed the block gas limit if a sufficient number of liquidations have occurred since the user's deposit.

Mitigation

Implement an alternative approach for tracking liquidity instead of looping. Consider using a mechanism similar to the rewardDebt approach from the MasterChef contract.