Summary

The system is said to work with EIP20 complaint tokens, however the code is not configured to do so, meaning that even complaint tokens will revert in some cases.

Vulnerability Details

First let us check the EIP and understand it before looking at the bug. As some of you know EIPs have key works like must and must not or should and should not, which should be strictly followed, and not following these must statements makes your token not-compliant.

Here for example is our compliance for the approve function - https://eips.ethereum.org/EIPS/eip-20

approve

Allows _spender to withdraw from your account multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value.

NOTE: To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender. THOUGH The contract itself shouldn’t enforce it, to allow backwards compatibility with contracts deployed before

Note that it's only making a recommendation to what should the contract implement and what it shouldn't, as it's missing any must or must not.

Now with that knowledge we can easily come to the conclusion that USDT is complaint, as it's not breaking any MUSTs by reverting if the allowance is not above 0 before making the next approval. This will cause _increaseAllowance to revert in any instances where the feeToken already has approval above 0.

Note that the provided context to the finding is crucial to understand the validity of this finding.

Impact

EIP20 compliant tokens will still revert inside _increaseAllowance

Tools Used

Manual review

Recommendations

Fix any approval by adding another approval to 0, before making the current one:

}