Submitted by IllIllI
CompoundHandler.sol#L71
CompoundHandler.sol#L120
AaveHandler.sol#L53
TopUpAction.sol#L847
OpenZeppelins safeApprove() will revert if the account already is approved and the new safeApprove() is done with a non-zero value.
OpenZeppelin/SafeERC20.sol#L45-L58
Customers cannot be topped up a second time, which will cause them to be liquidated even though they think theyre protected.
There are multiple places where safeApprove() is called a second time without setting the value to zero first. The instances below are all related to topping up.
Compound-specific top-ups will fail the second time around when approving the ctoken again:
CompoundHandler.sol#L50-L71
Compound-specific top-ups will also fail when trying to repay debt:
CompoundHandler.sol#L62-L65
Aave-specific top-ups will fail for the lendingPool:
AaveHandler.sol#L36-L53
The TopUpAction itself fails for the feeHandler:
TopUpAction.sol#L840-L847
Ive filed the other less-severe instances as a separate medium-severity issue, and flagged the remaining low-severity instances in my QA report.
Always do safeApprove(0) if the allowance is being changed, or use safeIncreaseAllowance().
chase-manning (Backd) confirmed and resolved
