validateVariablePoolHasEnoughLiquidity will always fail causing complete DOS to the protocol

[howlbot-integration]

Lines of code

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

Vulnerability details

Impact

buyCreditMarket, sellCreditMarket and liquidateWithReplacement all call validateVariablePoolHasEnoughLiquidity in the end of their execution to make sure that there is enough liquidity in the AAVE V3 pool. The issue is that the validation in validateVariablePoolHasEnoughLiquidity is critically wrong and will fail when used with the actual AAVE protocol.

As a result borrowing and lending will be completely blocked.

Proof of Concept

Here is the validation performed in validateVariablePoolHasEnoughLiquidity:

uint256 liquidity = state.data.underlyingBorrowToken.balanceOf(address(state.data.variablePool));
if (liquidity < amount) {
    revert Errors.NOT_ENOUGH_BORROW_ATOKEN_LIQUIDITY(liquidity, amount);
}

As we can see, the balance of the underlying borrow token (USDC) of the pool is derived as the balance of address(state.data.variablePool). The issue is that AAVE stores the underlying tokens in the individual AToken smart contracts, not the Pool contract. There are multiple ways we can understand this.
Firstly, looking into the USDC balances of the Pool and AToken contracts on Etherscan.
Secondly, looking into the supply and withdraw functions on AAVE:
1/ Pool.sol -> supply() -> SupplyLogic.executeSupply():

IERC20(params.asset).safeTransferFrom(msg.sender, reserveCache.aTokenAddress, params.amount);

We can see in the executeSupply function, called in supply, that the supplied underlying tokens are transferred directly from the sender (Size) to the AToken contract.

2/ Pool.sol -> withdraw() -> SupplyLogic.executeWithdraw():
Here we can see that no token transfers are occuring and the transfers are actually performed in the AToken contract (https://etherscan.io/address/0x98C23E9d8f34FEFb1B7BD6a91B7FF122F4e16F5c#readProxyContract), in the burn function:

function burn(
  address from,
  address receiverOfUnderlying,
  uint256 amount,
  uint256 index
) external virtual override onlyPool {
  _burnScaled(from, receiverOfUnderlying, amount, index);
  if (receiverOfUnderlying != address(this)) {
    IERC20(_underlyingAsset).safeTransfer(receiverOfUnderlying, amount);
  }
}

As a result, buyCreditMarket, sellCreditMarket will always fail when calling
validateVariablePoolHasEnoughLiquidity, and lending/borrowing will never work.

Tools Used

Manual review

Recommended Mitigation Steps

In validateVariablePoolHasEnoughLiquidity, use the AToken contract, not the Pool contract:

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

Assessed type

Invalid Validation

[c4-judge]

hansfriese marked the issue as satisfactory

[c4-judge]

hansfriese changed the severity to 2 (Med Risk)