Underflow in _createLegInAMM #357
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-516
partial-25
Incomplete articulation of vulnerability; eligible for partial credit only (25%)
Lines of code
https://github.com/code-423n4/2023-11-panoptic/blob/aa86461c9d6e60ef75ed5a1fe36a748b952c8666/contracts/SemiFungiblePositionManager.sol#L979
Vulnerability details
Impact
removedLiquidity -= chunkLiquidity;
will underflow when there is no removedLiquidity in a particular leg.This is a result of the fact that, when a token is being burnt, the tokenId is flipped to change the
isLong
to from 1 to 0, this happens for all the legs.The problem with here is that not all legs will be 1, some will retain their zero(0 when no liquidity was previously removed). For this reason,
removedLiquidity = 0
for such legs, but it was assumed that once the flag is BURN, removeLiquidity will be positive.Since the calculation happened in an unchecked block, it won't revert but underflow, increasing removedLiquidity to a very large amount. here
When
_createPositionInAMM
loops through every leg to create a position in AMM, it calls_createLegInAMM
which checks theProof of Concept
For a tokenId with two legs for instance, the first leg has
isLeg = 1
, the second leg hasisLong = 0
, when flipped, 1 changes to 0, in the first leg, but the second leg remains 0, butremovedLiquidity -= chunkLiquidity;
is still computed assuming that the zero was as a result of theflipToBurnToken
codeTools Used
Manual review.
Recommended Mitigation Steps
Add a check to ensure
removedLiquidity >= chunkLiquidity
Assessed type
Math
The text was updated successfully, but these errors were encountered: