The TokenManager contract has a vulnerability where the Withdrawal of tokens will revert if the amount exceeds the approved allowance and the allowance is not reset to zero. This can disrupt protocol activities and affect many users.
The root cause of the vulnerability is that the contract requires the allowance to be zero before extending it.
Found in src/core/TokenManager.sol at Line 245
@>: The condition to extend the allowance strictly waits for the allowance to be set to 0x0 before invoking the next
approve()call. This creates a vulnerability where the withdrawal amount exceeds the approved amount, but a new approval cannot be initiated. As a result, the next_safe_transfer_fromcall at Line 250 will revert due to insufficient allowances.
The likelihood of this occurring could be ranging in Med if protocol's activities are high, causing allowance to drain fast. The impact is High because it may lead to frequent reverts and disruption of protocol activities, potentially affecting many users.
Let us walk through the issue with the following scenario:
After sometime of operation, the TokenManager's WETH allowances to draw funds from CapitalPool is reduced to a dust value of 1 wei.
Alice tries to withdraw 1 WETH, but due to the strict condition that the WETH allowance must be 0x0, the new approval at line 247 is not called, causing a revert of Insuffient Allowances when TokenManager trying to withdraw 1 WETH from CapitalPool.
The issue persists across many users like Alice until someone who:
Figures out the coding problem (which may take some time).
Has a claimAmountAmount from userTokenBalanceMap of 1 wei (less likely).
Finally, deliberately calls withdraw() to clear out the allowance to 0x0.
From these reasons, the impact could be critical due to the high number of users affected and the rarity of recovery.
Manual Review
Instead of waiting till 0x0 allowance reached, try to check the remaining allowances against the transfer amount _amount to get the necessary extension in-time.
I believe this is invalid, - For weird ERC20s with front-running approval protection such as UDST (only known instance so far), max approval is likely only required to be invoked once, considering the supply cap of such tokens. (USDT supply is at 53.8 billion (53.8e9 * 1e9, so this is 100% sufficient) - If approvals are insufficient, a new proxy for tadle market can always be deployed via the TadleFactory contract and migrated
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.