Closed code423n4 closed 1 year ago
0xSorryNotSorry marked the issue as primary issue
outdoteth marked the issue as sponsor acknowledged
In contrast to low decimals issues, which are more common, very few if no token has 36 decimals, even safeMoon has 24
I also know that Yearn V2, which has been battle tested for over 2 years now, also doesn't support tokens with more than 36 decimals and have yet to see an issue with it
Am downgrading to QA for that reason
L
GalloDaSballo changed the severity to QA (Quality Assurance)
Lines of code
https://github.com/code-423n4/2023-04-caviar/blob/main/src/PrivatePool.sol#L742-L746
Vulnerability details
Impact
When dealing with baseToken with decimals over 36,
price()
in PrivatePool will revert, affectingdeposit()
in EthRouter that is externally callingprice()
.Proof of Concept
Here is the scenario:
ERC20(baseToken).decimals() = 38 exponent = 36 - 38 = -2 (leads to underflow and function reverts)
File:PrivatePool.sol#L742-L746
Consequently,
EtnRouter.deposit()
also reverts on line 233 of the code block below:File: EthRouter.sol#L233-L236
Tools Used
Manual
Recommended Mitigation Steps
Since exponentiation power is not allowed to be a signed integer type in Solidity, consider having the affected code block refactored with a different logic.
Here is a useful pure function that may be implemented in PrivatePool.sol:
With this,
price()
may be refactored as follows: