Description
While the protocol is compatible with tokens containing 18 decimals or fewer, it encounters issues with tokens having more than 18 decimals, such as YAMv2
with 24 decimals. The susceptible part of the code resides within LiquidationPool::distributeAssets()
, specifically on line 220. Here, the costInEuros
variable is calculated with 18 decimal places by scaling the _portion
variable with 10 ** (18 - asset.token.dec)
. This calculation is prone to underflow when dealing with tokens having more than 18 decimals.
Impact
The vulnerability causes rewards from liquidated smart vaults to become permanently locked within the contract. Stakers will be unable to claim these rewards due to the consistent failure of LiquidationPool::distributeAssets()
whenever assets with over 18 decimals are involved.
Proof of Concept
A demonstration using Foundry showcasing the reversion of LiquidationPool::distributeAssets()
when employing the YAM
mock token can be accessed here.
Recommended Mitigation
Consider augmenting the code to upscale and downscale the _portion
variable, ensuring it maintains a consistent 18 decimal format without encountering underflow issues.
Tools Used
Manual Review
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.