# Handle broccoli # Vulnerability details ## Impact In the burn function of ConcentratedLiquidityPool, when calling _updatePosition, the amount of liquidity to burn is explicitly converted from uint128 to int128, which could result in a positive integer if amount is larger than (1 << 127) and less than (1 << 128) (i.e., the MSB of amount is set). As a result, the pool's liquidity decreases, but the attacker's liquidity at a specific location increases. The incorrect liquidity could affect all trades in the pool afterward. ## Proof of Concept 1. Suppose that the current price is at the tick 500000. Consider an attacker calling the burn function with lower = upper = 50000, and amount = (1 << 128) - 100000. 2. Since the current price, the lower price, and the upper price are all the same (there's no check to ensure that the upper price should be greater than the lower price), the amount0 and amount1 to be withdrawn from the pool will both be 0. The pool's liquidity is decreased by amount (and could underflow to a large number). 3. However, when the _updatePosition function is called, the liquidity to update is calculated by -int128(amount) = -int128((1 << 128) - 100000) = -(-100000) = 100000, which causes the attacker's liquidity at positions[attacker][lower][lower] to be increased by 100000. 4. In short, the attacker does not have to prepare any liquidity at any position to control (pump or decrease) the pool's liquidity. Due to the incorrect liquidity value, all swaps afterward are affected. 5. Moreover, the attacker could potentially exploit the controlled liquidity value to profit from the pool. Referenced code: [ConcentratedLiquidityPool.sol#L252]() ## Recommended Mitigation Steps In the burn function, check the amount exceeds type(uint128).max or not. If so, then revert the transaction. Or consider using the [SafeCast library]() from OpenZeppelin instead. --- The text was updated successfully, but these errors were encountered: All reactions