Wrong liquidity checking lead to token being stuck

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-06-size/blob/8850e25fb088898e9cf86f9be1c401ad155bea86/src/libraries/CapsLibrary.sol#L67-#L71

Vulnerability details

Vulnerability details

Function validateVariablePoolHasEnoughLiquidity() is used to check if pool have enough token or not:

function validateVariablePoolHasEnoughLiquidity(State storage state, uint256 amount) public view {
    uint256 liquidity = state.data.underlyingBorrowToken.balanceOf(address(state.data.variablePool));  // <---
    if (liquidity < amount) {
        revert Errors.NOT_ENOUGH_BORROW_ATOKEN_LIQUIDITY(liquidity, amount);
    }
}

Notice that it use address state.data.variablePool, which have supply() function, that is Pool contract in aave docs:

function depositUnderlyingBorrowTokenToVariablePool(State storage state, address from, address to, uint256 amount)
    external
{
    state.data.underlyingBorrowToken.safeTransferFrom(from, address(this), amount);

    IAToken aToken =
        IAToken(state.data.variablePool.getReserveData(address(state.data.underlyingBorrowToken)).aTokenAddress);

    uint256 scaledBalanceBefore = aToken.scaledBalanceOf(address(this));

    state.data.underlyingBorrowToken.forceApprove(address(state.data.variablePool), amount);
    state.data.variablePool.supply(address(state.data.underlyingBorrowToken), amount, address(this), 0);  // <---

    uint256 scaledAmount = aToken.scaledBalanceOf(address(this)) - scaledBalanceBefore;

    state.data.borrowAToken.mintScaled(to, scaledAmount);
}

Look at aave's deposit workflow:

function supply(
    address asset,
    uint256 amount,
    address onBehalfOf,
    uint16 referralCode
) public virtual override {
    SupplyLogic.executeSupply(    // <----
        _reserves,
        _reservesList,
        _usersConfig[onBehalfOf],
        DataTypes.ExecuteSupplyParams({
            asset: asset,
            amount: amount,
            onBehalfOf: onBehalfOf,
            referralCode: referralCode
        })
    );
}

It call executeSupply() function in SupplyLogic library:

function executeSupply(
    mapping(address => DataTypes.ReserveData) storage reservesData,
    mapping(uint256 => address) storage reservesList,
    DataTypes.UserConfigurationMap storage userConfig,
    DataTypes.ExecuteSupplyParams memory params
) external {
    .  .  .  .  .  .  .  .  .
    ValidationLogic.validateSupply(reserveCache, reserve, params.amount);

    reserve.updateInterestRates(reserveCache, params.asset, params.amount, 0);

    IERC20(params.asset).safeTransferFrom(msg.sender, reserveCache.aTokenAddress, params.amount);  // <---
    .  .  .  .  .  .  .  .  .
}

It can be seen that token is transfered to reserveCache.aTokenAddress address, not stay in pool address, which lead to checking condition in validateVariablePoolHasEnoughLiquidity function wrong, token can be stuck due to wrong checking condition

Impact

As token stay in reserveCache.aTokenAddress address, which is AToken contract link, this wrong checking condition can lead to unintended revert, and user's token can be stuck inside protocol

Tools Used

Manual review

Recommended Mitigation Steps

Replace state.data.variablePool address to AToken's address.

Assessed type

Other

[c4-judge]

hansfriese marked the issue as satisfactory

[c4-judge]

hansfriese changed the severity to 2 (Med Risk)