stake.link

stake.link
DeFiHardhatBridge
27,500 USDC
View results
Submission Details
Severity: medium
Invalid

Potential minting disruption and duplicate entry addition in `SDLPoolSecondary` Contract

Summary

The SDLPoolSecondary contract has a vulnerability where the _mintStartIndex parameter in the handleIncomingUpdate function is not validated for zero values. If an attacker manipulates the _mintStartIndex value by passing zero from the primary chain, it can lead to unnecessary array items with zero values being added, resulting in duplicate entries and potential gas waste.

Additionally, there is a risk of reverting when the same user calling handleIncomingUpdate with a new _mintStartIndex after updateInProgress has been set to 0.

Vulnerability Details

The vulnerability arises from the inclusion of _mintStartIndex without proper validation in the currentMintLockIdByBatch array. If _mintStartIndex is zero, it can be added to the array, influencing the minting process and causing the addition of many duplicate entries with zero values. This lack of validation extends from the Primary Chain, where _mintStartIndex is not checked for zero values when constructing the CCIP message, to the Secondary Chain's handleIncomingUpdate function, allowing zero values to be added to the array during incoming updates.

And another issue is that incase if someone mistakenly pass _mintStartIndex as zero and the state of updateInProgress is updated to zero, so this user call will be rejected at second time because the state is updated already!

Impact

The issue may result in the addition of numerous duplicate entries with zero values in the currentMintLockIdByBatch array, leading to inefficiencies, potential storage bloat, and disruptions in the minting process.

There is a risk of reverting when attempting to call handleIncomingUpdate with a new _mintStartIndex after updateInProgress has been set to 0.

Tools Used

Manual review.

Recommendations

  1. Implement thorough validation checks on input parameters, specifically _mintStartIndex, both when constructing CCIP messages on the Primary Chain and when processing incoming updates on the Secondary Chain. Ensure that zero values are appropriately handled to prevent unintended consequences and the addition of duplicate entries in the minting logic.

  2. Consider using require statements or other validation mechanisms to ensure that only valid inputs are accepted, enhancing the robustness and security of the minting process.

e.g Add the below check on all chains contract code where the start index validation is needed:

// Validate that _mintStartIndex is not zero before processing
require(_mintStartIndex != 0, "Invalid _mintStartIndex");
Updates

Lead Judging Commences

0kage Lead Judge over 1 year ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

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