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

Malicious Actors Can Exploit Large Calldata Arrays to Cause DOS Attacks and Transaction Failures in Batch Functions

eta

Summary

The issue is the lack of a maximum length restriction for calldata arrays in batch functions such as batchAddLiquidity, batchRemoveLiquidity, batchRedeemPositionToken, batchRedeemWToken, and batchClaimYield in the AaveDIVAWrapper.sol contract. This omission may result in excessive gas consumption and a potential vector for denial-of-service (DOS) attacks.

Vulnerability Details

contracts/src/AaveDIVAWrapper.sol:batchCreateContingentPool#L113-L115

contracts/src/AaveDIVAWrapper.sol:batchAddLiquidity#L126

contracts/src/AaveDIVAWrapper.sol:batchRemoveLiquidity#L138-L140

contracts/src/AaveDIVAWrapper.sol:batchRedeemPositionToken#L155-L157

contracts/src/AaveDIVAWrapper.sol:batchRedeemWToken#L172-L174

contracts/src/AaveDIVAWrapper.sol:batchApproveCollateralTokenForAave#L202

function batchCreateContingentPool( PoolParams[] calldata _poolParams) external override nonReentrant returns (bytes32[] memory) {}
​
function batchAddLiquidity(AddLiquidityArgs[] calldata _addLiquidityArgs) external override nonReentrant {}
​
function batchRemoveLiquidity(RemoveLiquidityArgs[] calldata _removeLiquidityArgs) external override nonReentrant returns (uint256[] memory) {}
​
function batchRedeemPositionToken(RedeemPositionTokenArgs[] calldata _redeemPositionTokenArgs) external override nonReentrant returns (uint256[] memory) {}
​
function batchRedeemWToken(RedeemWTokenArgs[] calldata _redeemWTokenArgs) external override nonReentrant returns (uint256[] memory) {}
​
function batchApproveCollateralTokenForAave(address[] calldata _collateralTokens) external override {}

Each batch function processes multiple operations in a loop, with each iteration consuming gas. If the calldata array is excessively large:

  • The transaction's total gas usage could exceed the block gas limit, leading to transaction failure or an "out of gas" error.

  • This may also render the contract unusable in certain scenarios, especially when batch operations are critical for high-throughput use cases.

An attacker could deliberately pass a large calldata array to:

  • Prolong execution time for the transaction.

  • Consume a disproportionate amount of gas, potentially exhausting the resources of the network.

  • Delay the execution of other users' transactions by congesting the network with high gas-consuming operations.

Impact

  • Gas Efficiency and Failure: Unrestricted calldata array lengths can lead to inefficient gas usage and wasted user funds. And Transactions involving oversized calldata arrays are likely to fail.

  • Security: Large calldata arrays can be exploited to execute DOS attacks, rendering the contract temporarily inaccessible.

Tools Used

Manual Code Review

Recommendations

It is recommended to introduce a maximum batch size and add a constant to define the maximum allowable length for calldata arrays as well as implement length checks in all batch functions to ensure calldata arrays do not exceed the defined limit. For example:

uint256 private constant MAX_BATCH_SIZE = 100; // @audit Adjust based on business needs and gas tests
​
function batchAddLiquidity(AddLiquidityArgs[] calldata _addLiquidityArgs) external override nonReentrant {
uint256 _length = _addLiquidityArgs.length;
if (_length > MAX_BATCH_SIZE) revert BatchSizeTooLarge();
for (uint256 i = 0; i < _length; i++) {
_addLiquidity(
_addLiquidityArgs[i].poolId,
_addLiquidityArgs[i].collateralAmount,
_addLiquidityArgs[i].longRecipient,
_addLiquidityArgs[i].shortRecipient
);
}
}
Updates

Lead Judging Commences

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

Support

FAQs

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