# Missing Update to `omnichain.totalAvailableLiquidationAmount` in `withdrawUser` Crit/High · Sherlock · Hedged stablecoin · 4th December 2024 Finding H-28 of the Autonomint competition. - Protocol: https://audits.sherlock.xyz/contests/569 - Report: /reports/autonomint - Codebase: https://github.com/0xsimao/2024-11-autonomint/tree/0d324e04d4c0ca306e1ae4d4c65f0cb9d681751b - Source: https://github.com/sherlock-audit/2024-11-autonomint-judging/issues/930 --- ### Summary In the [`deposit`](https://github.com/sherlock-audit/2024-11-autonomint/blob/0d324e04d4c0ca306e1ae4d4c65f0cb9d681751b/Blockchain/Blockchian/contracts/lib/CDSLib.sol#L546) function we update `omnichain.totalAvailableLiquidationAmount` based on the enw deposit, however The [`Withdraw`](https://github.com/sherlock-audit/2024-11-autonomint/blob/0d324e04d4c0ca306e1ae4d4c65f0cb9d681751b/Blockchain/Blockchian/contracts/lib/CDSLib.sol#L609) function processes user withdrawals but fails to update the `omnichain.totalAvailableLiquidationAmount.` This omission creates a discrepancy between the protocol's actual liquidation capacity and the recorded available amount. While the deposit function correctly adjusts this value, the absence of an update during withdrawals leads to an inflated `totalAvailableLiquidationAmount,` potentially allowing the protocol to overcommit its liquidation resources. ### Root Cause 1. The `withdrawUser` function processes user withdrawals without adjusting the `omnichain.totalAvailableLiquidationAmount` to reflect the reduced CDS pool. 2. The `deposit` function, in contrast, correctly updates this value when users contribute to the CDS pool. ### Internal pre-conditions _No response_ ### External pre-conditions _No response_ ### Attack Path 1. A user withdraws their CDS funds, but the protocol does not update omnichain.totalAvailableLiquidationAmount. 2. During liquidation, the protocol calculates user shares based on the inflated value. 3. The overestimated `totalAvailableLiquidationAmount` causes some liquidation gains to remain undistributed, locking funds in the protocol. ### Impact 1. A portion of liquidation gains remains locked in the CDS pool, reducing the funds distributed to eligible users. 2. Remaining CDS participants receive a smaller share of the liquidation gains than they are entitled to. ### PoC 1. State Before Withdrawal: - omnichain.totalAvailableLiquidationAmount = 1,000,000 USDa. - User withdraws 200,000 USDa. 2. Expected Behavior: - omnichain.totalAvailableLiquidationAmount is reduced to 800,000 USDa. 3. Actual Behavior: - omnichain.totalAvailableLiquidationAmount remains 1,000,000 USDa. 4. During Liquidation: - Assume liquidation generates 500,000 USDa in gains. - Share calculation uses the inflated 1,000,000 USDa instead of the actual 800,000 USDa. - 100,000 USDa of the gains remains locked due to the overestimated pool size. ### Mitigation ```javascript params.omniChainData.totalAvailableLiquidationAmount -= params.cdsDepositDetails.withdrawedAmount; ``` I should note there seems to be no update on omnichain, this should be looked at --- Related findings: - [Inconsistent updateTotalAssets modifier usage](https://0xsimao.com/findings/yieldoor-ii-inconsistent-assets-modifier-usage): Yieldoor LoopedVault - [RebalanceLogic::rebalanceCallback() doesn't update lastTotalAssets when rebalancing from morpho to morpho](https://0xsimao.com/findings/yieldoor-ii-rebalance-callback-rebalancing-morpho): Yieldoor LoopedVault - [Vesting interest is not reset to 0 in case there is no interest in LoopedVault11::updateTotalAssets()](https://0xsimao.com/findings/yieldoor-ii-vesting-interest-reset-vault11): Yieldoor LoopedVault - [An attacker may DoS user Fluid balance increases by frontrunning `FluidLocker::claim()` calls and calling `EP_PROGRAM_MANAGER::batchUpdateUserUnits()` directly](https://0xsimao.com/findings/superfluid-locker-system-increases-frontrunning-program-directly): Superfluid Locker System