0x73696d616f - VaultLib::__addLiquidityToAmmUnchecked() does not deal with the remaining amounts not sent to the amm, losing them

[sherlock-admin2]

0x73696d616f

High

VaultLib::__addLiquidityToAmmUnchecked() does not deal with the remaining amounts not sent to the amm, losing them

Summary

VaultLib::__addLiquidityToAmmUnchecked() sets a tolerance for the Ra and Ct tokens to provide liquidity, which means it will not revert in case the tokens up to the tolerance are not provided as liquidity to the Amm. However, it does not track the funds that were not provided to the liquidity, leaving them untracked in the Vault.

Root Cause

In VaultLib:45, the remaining Ra and Ct not provided as liquidity are left untracked and are lost.

Internal pre-conditions

None.

External pre-conditions

None.

Attack Path

VaultLib::__addLiquidityToAmmUnchecked() is called by VaultLib::__provideLiquidity(), called by VaultLib::__provideLiquidityWithRatio() or __provideAmmLiquidityFromPool(), called when a fee is minted from user actions or a new issuance is started.

Impact

The protocol is left with stuck Ra and Ct.

PoC

VaultLib.sol

function __addLiquidityToAmmUnchecked(
    State storage self,
    uint256 raAmount,
    uint256 ctAmount,
    address raAddress,
    address ctAddress,
    IUniswapV2Router02 ammRouter
) internal {
    (uint256 raTolerance, uint256 ctTolerance) =
        MathHelper.calculateWithTolerance(raAmount, ctAmount, MathHelper.UNIV2_STATIC_TOLERANCE);
    ...
    (,, uint256 lp) = ammRouter.addLiquidity( //@audit remaining amounts are not checked
        token0, token1, token0Amount, token1Amount, token0Tolerance, token1Tolerance, address(this), block.timestamp
    );
    ...
}

Mitigation

Get the actually provided amounts and track the unprovided to liquidity amounts to be dealt with.

Duplicate of #240