Transferring 0 amounts of non-existent tokens when all liquidity is removed results in unexpected behaviors #498
Labels
3 (High Risk)
Assets can be stolen/lost/compromised directly
bug
Something isn't working
duplicate-256
satisfactory
satisfies C4 submission criteria; eligible for awards
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Lines of code
https://github.com/code-423n4/2023-11-panoptic/blob/aa86461c9d6e60ef75ed5a1fe36a748b952c8666/contracts/tokens/ERC1155Minimal.sol#L90-L118
https://github.com/code-423n4/2023-11-panoptic/blob/aa86461c9d6e60ef75ed5a1fe36a748b952c8666/contracts/SemiFungiblePositionManager.sol#L586-L630
Vulnerability details
Impact
Currently, ERC1155Minimal.sol allows 0 transfers, which means that tokens that were not minted can be "transferred". Normally this wouldn't be a problem, but in
registerTokenTransfer
a 0 transfer can actually transfer non-zero liquidity due to the possibility of different token ids sharing the same liquidity position key.This could lead to unexpected scenarios in which liquidity gets trapped or removedLiquidity underflows, affecting the calculation of premiums and fees.
Proof of Concept
Here is a simple test example that exploits the mentioned behavior to reach an unexpected state https://gist.github.com/fnanni-0/8ebb660b1d4ef518a409e2b82b293113.
Running
forge test -vv --match-test test_Success_ZeroTransfers
outputs a step by step explanation of what is happening:Tools Used
Code inspection.
Recommended Mitigation Steps
Block transfers of non-existent tokens (i.e. block transfers with zero amounts).
Assessed type
Token-Transfer
The text was updated successfully, but these errors were encountered: