Skip to content
This repository has been archived by the owner on Oct 1, 2023. It is now read-only.

hickuphh3 - Minting queue deposits / rollovers fails after ~24.5k enrollments as it exceeds arbitrum gas limit #79

Closed
sherlock-admin opened this issue Mar 27, 2023 · 0 comments
Labels
Duplicate A valid issue that is a duplicate of an issue with `Has Duplicates` label Medium A valid Medium severity issue Reward A payout will be made for this issue

Comments

@sherlock-admin
Copy link
Contributor

sherlock-admin commented Mar 27, 2023

hickuphh3

medium

Minting queue deposits / rollovers fails after ~24.5k enrollments as it exceeds arbitrum gas limit

Summary

Minting rollovers / deposits will revert once there are ~24.5k enrolments / queue deposits as it exceeds Arbitrum's 32M L2 gas limit.

Vulnerability Detail

While it may seem that Arbitrum has an extremely large gas limit:
image
this huge number given is for L1 calldata gas. Arbitrum's execution gas limit for transactions is 32 million.

The entire deposit queue is copied over from storage to memory in mintDepositInQueue():

QueueItem[] memory queue = depositQueue;

and the rollover queue in mintRollovers():

QueueItem[] memory queue = rolloverQueue;

And because the deposit and rollover queues are unbounded, it is possible for these operations to run out of gas. With a Foundry test, that number seems to be around 24_500 users.

function testManyRollovers() public {
      // setup
      uint40 _epochBegin = uint40(block.timestamp + 1 days);
      uint40 _epochEnd = uint40(block.timestamp + 2 days);
      uint256 _epochId = 2;
      uint256 _emissions = 100 ether;

      deal(emissionsToken, address(vault), 100 ether, true);
      vault.setEpoch(_epochBegin, _epochEnd, _epochId);
      vault.setEmissions( _epochId, _emissions);
  
      helperDepositInEpochs(_epochId, USER, false);

      // transfer asset to numUsers
      // then for each user, enlist into queue
      uint256 numUsers = 24_500;
      uint256 assetAmt = relayerFee * 3 / 2;
      for (uint i = 1000; i < 1000 + numUsers; ++i) {
          vm.prank(USER);
          address enlister = address(uint160(i));
          vault.safeTransferFrom(USER, enlister, _epochId, assetAmt, "");
          vm.prank(enlister);
          vault.enlistInRollover(_epochId, assetAmt, enlister);
      }

      // resolve first epoch
      vm.warp(_epochEnd + 1 days);
      vm.startPrank(controller);
      vault.resolveEpoch(_epochId);
      vm.stopPrank();

      // create second epoch
      _epochBegin = uint40(block.timestamp + 1 days);
      _epochEnd = uint40(block.timestamp + 2 days);
      _epochId = 3;
      _emissions = 100 ether;

      deal(emissionsToken, address(vault), 100 ether, true);
      vault.setEpoch(_epochBegin, _epochEnd, _epochId);
      vault.setEmissions( _epochId, _emissions);

      vm.startPrank(relayer);
      uint256 startGas = gasleft();
      // mint 1 rollover
      vault.mintRollovers(_epochId, 1);
      uint256 endGas = gasleft();
      console.log("Gas used", startGas - endGas);
      vm.stopPrank();
  }

Impact

Minting rollovers / queue deposits will revert once there are ~24.5k enrollments / queue deposits.

Code Snippet

https://github.com/sherlock-audit/2023-03-Y2K/blob/main/Earthquake/src/v2/Carousel/Carousel.sol#L318
https://github.com/sherlock-audit/2023-03-Y2K/blob/main/Earthquake/src/v2/Carousel/Carousel.sol#L387

Tool used

  • Manual Review
  • Special thanks to Gzeon answering my query about Arbitrum's gas limit!

Recommendation

Instead of copying the entire deposit / rollover queue, copy only the queue item when it's required.

- QueueItem[] memory queue = rolloverQueue;
// account for how many operations have been done
uint256 prevIndex = index;
uint256 executions = 0;

while ((index - prevIndex) < (_operations)) {
+  QueueItem memory queueItem = rolloverQueue[index];
+ // TODO: replace queue[index] with queueItem

With the same test, one will find that the gas usage drops from 32_518_067 to a mere 13_216.

Duplicate of #174

@github-actions github-actions bot closed this as completed Apr 3, 2023
@github-actions github-actions bot added Medium A valid Medium severity issue Duplicate A valid issue that is a duplicate of an issue with `Has Duplicates` label labels Apr 3, 2023
@sherlock-admin sherlock-admin added the Reward A payout will be made for this issue label Apr 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate A valid issue that is a duplicate of an issue with `Has Duplicates` label Medium A valid Medium severity issue Reward A payout will be made for this issue
Projects
None yet
Development

No branches or pull requests

1 participant