The user doesn't get the unused paymentToken refund if the UniswapV2 slipped during addLiquidity

Summary

The actual amount of tokenB (paymentToken in the OptionTokenV4 contract) used by the UniswapV2Router02 contract's addLiquidity function may differ from how much was charged from the user at the beginning of the _exerciseVe call by the OptionTokenV4 contract.

Vulnerability Detail

For large exerciseVe calls, it really makes sense to refund the user with the unused paymentToken that is left in the contract after the liquidity is added, otherwise the leftovers of paymentToken that Uniswap V2 didn't charge during addLiquidity are stuck in the OptionTokenV4 contract/

Impact

Minor losses of user funds in paymentToken, but this may accumulate over time.

Code Snippet

There're no checks for the real amount of either tokenA or tokenB that were charged:

        (, , lpAmount) = IRouter(router).addLiquidity(
            underlyingToken,
            paymentToken,
            false,
            _amount,
            paymentAmountToAddLiquidity,
            1,
            1,
            address(this),
            block.timestamp
        );

https://github.com/sherlock-audit/2024-06-velocimeter/blob/63818925987a5115a80eff4bd12578146a844cfd/v4-contracts/contracts/OptionTokenV4.sol#L626

Note that the UniswapV2Router02 interface provides these as return variables:

function addLiquidity(
  address tokenA,
  address tokenB,
  uint amountADesired,
  uint amountBDesired,
  uint amountAMin,
  uint amountBMin,
  address to,
  uint deadline
) external returns (uint amountA, uint amountB, uint liquidity);

(https://docs.uniswap.org/contracts/v2/reference/smart-contracts/router-02#addliquidity)

Tool used

Manual review.

Recommendation

Consider refunding the user the difference between paymentAmountToAddLiquidity and addLiquidity's real amountB.

sherlock-audit / 2024-06-velocimeter-judging

Decent Mandarin Pangolin - The user doesn't get the unused paymentToken refund if the UniswapV2 slipped during addLiquidity #701