HardhatDeFi
15,000 USDC
View results
Submission Details
Severity: low
Invalid

Yield calculation may become inaccurate if more wTokens are minted than expected (AaveDIVAWrapperCore.sol::_getAccruedYieldPrivate)

Summary

The _getAccruedYieldPrivate function in the AaveDIVAWrapperCore contract calculates the yield by comparing the aTokenBalance (Aave token balance held by the contract) to the wTokenSupply (total supply of the wrapped token). If wTokenSupply exceeds aTokenBalance, the function incorrectly returns zero, even if there is accrued interest.

Vulnerability Details

481:function _getAccruedYieldPrivate(address _collateralToken) private view returns (uint256) {
uint256 aTokenBalance = IERC20Metadata(IAave(_aaveV3Pool).getReserveData(_collateralToken).aTokenAddress)
.balanceOf(address(this));
uint256 wTokenSupply = IERC20Metadata(_collateralTokenToWToken[_collateralToken]).totalSupply();
// Handle case where the aToken balance might be smaller than the wToken supply (e.g., due to rounding).
// In that case, the owner should just wait until yield accrues.
return aTokenBalance > wTokenSupply ? aTokenBalance - wTokenSupply : 0;
}
  1. Incorrect Assumption:

    • The function assumes that wTokenSupply accurately reflects the deposited principal on Aave. This assumption fails if wTokenSupply is manipulated or desynchronized (e.g., through improper minting or re-entrancy).

  2. Suppression of Yield:

    • If wTokenSupply exceeds aTokenBalance, the calculated yield reverts to zero, potentially locking accrued interest within the contract.

  3. Rounding Issues:

    • The comments in the code mention rounding concerns, but these do not address cases where wTokenSupply is inflated beyond aTokenBalance due to bugs or exploits.

  4. Lack of Emergency Recovery:

    • There is no fallback mechanism to recover and redistribute yield in case of a desynchronization between aTokenBalance and wTokenSupply.

Impact

This vulnerability can result in:

  • Suppression of yield calculations, causing users to be unable to claim accrued interest.

  • Exploitation by attackers to manipulate the wTokenSupply and disrupt normal operations.

  • Permanent locking of accrued interest in the contract, impacting user funds and protocol efficiency.

Tools Used

  • Manual code review of the _getAccruedYieldPrivate function implementation.

  • Analysis of contract assumptions and potential edge cases.

Recommendations

  1. Track Deposited Principal:

    • Implement a mechanism to track the actual deposited principal for each collateral token, instead of relying on wTokenSupply.

  2. Use Principal-Based Yield Calculation:

    • Replace the wTokenSupply dependency with a calculation based on the principal amount:

function _getAccruedYieldPrivate(address _collateralToken) private view returns (uint256) {
uint256 aTokenBalance = IERC20Metadata(IAave(_aaveV3Pool).getReserveData(_collateralToken).aTokenAddress)
.balanceOf(address(this));
- uint256 wTokenSupply = IERC20Metadata(_collateralTokenToWToken[_collateralToken]).totalSupply();
+ uint256 depositedPrincipal = getDepositedPrincipal(_collateralToken); // Accurate principal tracking
// Handle case where the aToken balance might be smaller than the wToken supply (e.g., due to rounding).
// In that case, the owner should just wait until yield accrues.
- return aTokenBalance > wTokenSupply ? aTokenBalance - wTokenSupply : 0;
+ return aTokenBalance > depositedPrincipal ? aTokenBalance - depositedPrincipal : 0;
}
Updates

Lead Judging Commences

bube Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Known issue

Support

FAQs

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