UniV2LiquidityAmo addLiquidity can be DoS'd #141
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
duplicate-1782
sufficient quality report
This report is of sufficient quality
unsatisfactory
does not satisfy C4 submission criteria; not eligible for awards
Lines of code
https://github.com/code-423n4/2023-08-dopex/blob/main/contracts/amo/UniV2LiquidityAmo.sol#L189-L250
Vulnerability details
Impact
The
safeApprove()
calls inaddLiquidity()
will revert if there is an existing non-zero allowance. This can happen if a previousaddLiquidity()
hasn't used up all token amounts.Description
In
addLiquidity()
both tokens are approved with safeApprove() which reverts if there is a non-zero allowance.The ratio of the added tokens in a Uniswap V2 LP-in operation is almost never guaranteed to be exactly as requested due to the ratio changing with every swap / lp action. If
addLiquidity()
leaves dust in a token, then there will be an outstanding non-zero approval for the token. Subseqquent calls toaddLiqudity()
will fail.Proof of Concept
The following Foundry test illustrates this vulnerability.
PoC.t.sol
under/test
forge test --match-test test_poc_amo -vvv
Tools Used
Manual review, Foundry
Recommended Mitigation Steps
Use
safeIncreaseAllowance
instead ofsafeApprove
.SafeERC20.safeApprove() Has unnecessary and unsecure added behavior #2219
Assessed type
ERC20
The text was updated successfully, but these errors were encountered: