Aave DIVA Wrapper
DIVA
HardhatDeFi
15,000 USDC
View results
Previous Next
Submission Details
Severity: high
Invalid

Missing Address Check for _longRecipient, _shortRecipient Addresses Leads to Stuck the Liquidity of the User in the Contract Forever.

rhaosec

Summary

The addLiquidity() and _addLiquidity() functions do not validate the _longRecipient and _shortRecipient addresses to ensure they are not the zero address (address(0)) or they are equal or right. This oversight could lead to a scenario where user liquidity remains permanently locked in the contract.

Vulnerability Details

The current implementation lacks explicit checks to validate _longRecipient and _shortRecipient addresses before proceeding with the liquidity addition operation.

function addLiquidity(
bytes32 _poolId,
uint256 _collateralAmount,
address _longRecipient,
address _shortRecipient
) external override nonReentrant {
_addLiquidity(_poolId, _collateralAmount, _longRecipient, _shortRecipient);
}
​
// which calls the _addLiquidity function of the AaveDIVAWrapperCore.sol
​
function _addLiquidity(
bytes32 _poolId,
uint256 _collateralAmount,
address _longRecipient,
address _shortRecipient
) internal {
// Verify that the collateral token used in the DIVA Protocol pool corresponds to a registered
// collateral token in the AaveDIVAWrapper contract. Returns zero address if the wToken is not registered.
IDIVA.Pool memory _pool = IDIVA(_diva).getPoolParameters(_poolId);
address _collateralToken = _wTokenToCollateralToken[_pool.collateralToken];
if (_collateralToken == address(0)) {
revert CollateralTokenNotRegistered();
}
​
_handleTokenOperations(_collateralToken, _collateralAmount, _pool.collateralToken);
​
// Add liquidity to the DIVA Protocol pool associated with the provided `_poolId`
// using the wToken and send the position tokens to the provided recipients.
IDIVA(_diva).addLiquidity(_poolId, _collateralAmount, _longRecipient, _shortRecipient);
}
​
​
​

And while _removeLiquidity function of the AaveDIVAWrapperCore.sol the tokens are transferedFrom the position address to this contract which will leads to liquidity stuck in this.

The calls to the transferFrom() function will fail if either _shortTokenContract or _longTokenContract is set to address(0) or uncontrolled address.

_shortTokenContract.transferFrom(msg.sender, address(this), _positionTokenAmountToRemove);
_longTokenContract.transferFrom(msg.sender, address(this), _positionTokenAmountToRemove);


The function flow may revert prematurely, and user liquidity will remain stuck, potentially creating a loss of user funds and bad user experience.

Impact

  • If either _longRecipient or _shortRecipient is set to the zero address or other address which is unctrollable by the user , the corresponding liquidity tokens cannot be claimed or transferred, causing the user's liquidity to become irretrievably stuck.

  • Potential financial loss.

Tools Used

Manual Review

Recommendations

Add proper checks for _longRecipient, _shortRecipient address in the smart contracts.

Updates

Lead Judging Commences

bube Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.