When depositing users can supply either/or n0 && n1 which represents the quote and base asset. When the current tick is within the tick ranges for the respective position, the user may receive both n0 & n1 even when depositing only one of the two assets.
The accounting in deposit doesn't consider this case and will cause the function to revert due to underflow, denying a user the ability to deposit assets unilaterally.
Proof of Concept
First to understand this case in UniswapV3Pool specifically:
Lines of code
https://github.com/code-423n4/2023-08-goodentry/blob/71c0c0eca8af957202ccdbf5ce2f2a514ffe2e24/contracts/TokenisableRange.sol#L222-L285
Vulnerability details
Impact
When depositing users can supply either/or
n0
&&n1
which represents the quote and base asset. When the current tick is within the tick ranges for the respective position, the user may receive bothn0
&n1
even when depositing only one of the two assets.The accounting in
deposit
doesn't consider this case and will cause the function to revert due to underflow, denying a user the ability to deposit assets unilaterally.Proof of Concept
First to understand this case in UniswapV3Pool specifically:
Here we can see the user is able to receive both quote & base.
In
TokenisableRange#deposit
these values are stored here:However the issue is caused here, where for example:
User deposits 0
n0
and receives Xadded0
due to depositing Yn1
& receives Zadded1
This will cause the function to revert due to the following check.
Tools Used
manual
Recommended Mitigation Steps
adjust accounting to consider case where user deposits 0
n0/n1
Assessed type
Math