The _calculateCurrentBlockWeight
function in QuantAMMWeightedPool.sol
contains an underflow vulnerability when the multiplier is negative. The issue occurs in the following calculation:
The function calculates the current block weight by subtracting a scaled multiplier times the time since the last update from the initial weight when the multiplier is negative. However, if timeSinceLastUpdate
is large enough, the multiplication result could exceed uint256(weight)
, causing an underflow.
The underflow vulnerability has severe implications:
Invalid Pool State: When the underflow occurs, the token weights will exceed 100% (1e18), violating a fundamental invariant of the pool that weights must sum to exactly 100%.
Economic Exploitation: Incorrect weights directly affect swap calculations and pool operations. An attacker could:
Execute trades at incorrect prices
Manipulate liquidity ratios
Extract value from the pool through arbitrage
Persistent Impact: Since the weights are used in critical paths like onSwap()
and _getNormalizedWeights()
, the invalid state affects all subsequent pool operations until fixed.
To fix this vulnerability, implement one or more of the following measures:
Add Weight Validation:
Time Bound Check:
Weight Bounds Check:
The recommended approach is to implement both the time bound check and weight bounds check to provide multiple layers of protection against the underflow condition.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
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.