BalancerUtils::_normalizeBalances will silently underflow if decimals are bigger than 18
Summary
If primaryDecimals or secondaryDecimals is bigger than 18, the BalancerUtils::_normalizeBalances will silently underflow and gives very wrong number.
Vulnerability Detail
If primaryDecimals or secondaryDecimals is bigger than 18, the BalancerUtils::_normalizeBalances will silently underflow and gives very wrong number.
For example, if the primaryDecimals is 24, the 18 - primaryDecimals will wrap around within uint8 and be 250, then the decimalAdjust will be 103127329476984736549117908523362667931818580092836127347641910757047631085568.
lemonmon
medium
BalancerUtils::_normalizeBalanceswill silently underflow if decimals are bigger than 18Summary
If
primaryDecimalsorsecondaryDecimalsis bigger than 18, theBalancerUtils::_normalizeBalanceswill silently underflow and gives very wrong number.Vulnerability Detail
If
primaryDecimalsorsecondaryDecimalsis bigger than 18, theBalancerUtils::_normalizeBalanceswill silently underflow and gives very wrong number. For example, if the primaryDecimals is 24, the18 - primaryDecimalswill wrap around within uint8 and be 250, then thedecimalAdjustwill be 103127329476984736549117908523362667931818580092836127347641910757047631085568.Some erc20 tokens have bigger than 18 decimals
Impact
The
_normalizeBalanceswill return incorrect values for tokens with bigger than 18 decimals.Code Snippet
https://github.com/sherlock-audit/2022-09-notional/blob/main/leveraged-vaults/contracts/vaults/balancer/internal/pool/BalancerUtils.sol#L38-L63
Tool used
Manual Review
Recommendation
Even if the contract is not meant to be used with bigger than 18 decimals, add a check to revert if the decimals are too big.