Part 2

Zaros
PerpetualsDEXFoundrySolidity
70,000 USDC
View results
Submission Details
Severity: medium
Invalid

Potential DoS through Large Input Array in LiquidationBranch.sol::liquidateAccounts()

Summary

The liquidateAccounts() function iterates over every account ID provided in the input array and performs multiple storage updates and complex operations for each account. If a malicious actor provides an excessively large array, the gas cost of processing the transaction may exceed the block gas limit, leading to out-of-gas errors and resulting in a denial-of-service (DoS) condition for legitimate liquidation attempts.

Vulnerability Details

The function is defined as follows:

function liquidateAccounts(uint128[] calldata accountsIds) external {
// ...
for (uint256 i; i < accountsIds.length; i++) {
ctx.tradingAccountId = accountsIds[i];
// ... heavy operations (clearing orders, updating positions, computing funding rates, etc.) ...
}
}

Since the function performs numerous storage operations and complex logic per iteration for each element in accountsIds, the gas consumption increases linearly with the length of the array. This makes the function susceptible to abuse if a very large list is provided. In such a scenario, the transaction may revert due to an out-of-gas condition, effectively preventing any liquidations within that block and potentially delaying the liquidation of underwater accounts.

Impact

  • Denial-of-Service (DoS): Legitimate liquidators may be unable to complete their liquidation transactions in a timely manner if the function call consumes excessive gas, delaying the liquidation process.

  • Operational Disruption: In a volatile market, delays in liquidation can result in increased risk and potential financial losses for the protocol and its traders.

  • Exploitation by Malicious Actors: An attacker could purposely submit a very large input array to disrupt the liquidation process and gain an advantage in volatile trading scenarios.

Tools Used

  • Manual Code Review: Inspection of the loop in liquidateAccounts() revealed the potential for high gas consumption.

  • Static Analysis: Analysis tools flagged concerns over loops iterating over user-provided arrays without bound.

  • Simulation Testing: Hypothetical scenarios were tested to estimate the gas cost impact of processing large arrays.

Recommendations

  • Input Array Length Limitation: Implement a maximum length check for the accountsIds array at the start of the function to prevent excessive gas consumption.

    require(accountsIds.length <= MAX_ALLOWED_ACCOUNTS, "Input array exceeds maximum allowed length");
  • Batch Processing: Consider splitting a large array into multiple smaller batches. Allow multiple calls to the function to process liquidations gradually rather than in a single transaction.

  • Optimized Processing: Explore optimizations in the liquidation logic to reduce gas cost per iteration, such as off-chain pre-processing or more efficient storage updates.

  • Gas Refunds or Incentives: Provide appropriate gas reimbursements or incentives for liquidators handling large datasets to mitigate the impact of higher gas costs.

Updates

Lead Judging Commences

inallhonesty Lead Judge 4 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.