afterUpdate::UpliftOnlyExample does not check poolsFeeData[pool][to].length is up to 100 before push
Summary
The afterUpdate function in the smart contract allows transferring fee data associated with a given _tokenID to a new recipient _to. However, there is no validation to ensure that the length of the poolsFeeData[poolAddress][_to] array does not exceed 100 before appending a new entry.
This violates the protocol's constraint, which explicitly disallows the poolsFeeData[poolAddress][_to] array from having more than 100 entries.
Vulnerability Details
Severity
High: This issue could lead to protocol rule violations, increased gas costs, and potential DoS scenarios, impacting the system's functionality and reliability.
Impact
If the length of the poolsFeeData[poolAddress][_to] array exceeds 100, it can:
Violate Protocol Rules: Breach the designed constraints of the protocol, potentially leading to unexpected behavior or invalid state.
Excessive Gas Costs: Handling oversized arrays could lead to increased gas consumption in subsequent operations, especially for loops and storage access.
Potential Denial of Service (DoS): Functions that iterate through the array could become unreasonably expensive or fail due to exceeding block gas limits.
Tools Used
Manual review
Recommendations
Lead Judging Commences
finding_afterUpdate_does_not_check_limit_NFT_per_user
Likelihood: Medium/High, anyone can receive an unlimited NFT number but will cost creation of LP tokens and sending them. Impact: Low/Medium, DoS the afterUpdate and addLiquidityProportional but will be mitigable on-chain because a lot of those NFT can be burn easily in onAfterRemoveLiquidity.
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.