Tadle

Summary

The transfer function in token manager compares the balances before and after the transfer to determine if the transfer was successful. However, this approach is flawed because it assumes that no other transfers or balance changes occur between the balance checks. In reality, balances could be altered by other transactions or contracts during the execution of this function, leading to incorrect conclusions about the transfer's success.

Vulnerability Details

race conditions on balances can lead to unexpected outcomes, especially when multiple transactions or contract calls are interacting with the same balance.

In this scenario, the race condition might occur as follows:

Initial Balance Check: The contract records the initial balance of _from.

External Call: Before or during the execution of transferFrom, an external contract or another transaction modifies the balance of _from. This could happen through a reentrancy attack, where the called contract (during the transferFrom operation) calls back into this contract or another contract to perform an additional transfer.

Final Balance Check: After the transferFrom operation, the contract checks the balance again and expects it to be the initial balance minus the _amount transferred. However, due to the external modification, the final balance might not match this expectation.

Impact

The transfer function will revert even when transfers go through

Tools Used

Manual Review

Recommendations

Use the safeTransfer module from openZeppelin, anything other than logging balance Before and after