V3Oracle.sol calculated the prices in a way that would revert upon reaching certain level when referenceToken was used with high decimal value (e. g. 18)
Mitigation
PR-21 successfully mitigates the original issue by refactoring the original price calculation so that it increments the dividend only by the decimal difference instead of the full token decimals
The original issue would still be present in case referenceTokenDecimals - feedConfig.tokenDecimals >=18. Chainlink feeds normally have lower decimals (USDC has 8), if the reference token has more than 18 token, lets say 26, the difference between the two would again equal 18.
It's not very likely the token would have that many decimals (especially considering its set by the protocol). That's why I'm including this as a QA comment here instead of turning it into a submission.
Lines of code
Vulnerability details
C4 Issue
M-07: Large decimal of referenceToken causes overflow at oracle price calculation
Issue Details
V3Oracle.sol
calculated the prices in a way that would revert upon reaching certain level when referenceToken was used with high decimal value (e. g. 18)Mitigation
PR-21 successfully mitigates the original issue by refactoring the original price calculation so that it increments the dividend only by the decimal difference instead of the full token decimals
Additional Comment
There is a gotcha in this part of the function:
The original issue would still be present in case
referenceTokenDecimals - feedConfig.tokenDecimals >=18
. Chainlink feeds normally have lower decimals (USDC has 8), if the reference token has more than 18 token, lets say 26, the difference between the two would again equal 18.It's not very likely the token would have that many decimals (especially considering its set by the protocol). That's why I'm including this as a QA comment here instead of turning it into a submission.
Conclusion
Mitigation Confirmed