Contracts are vulnerable to fee-on-transfer accounting-related issues

[code423n4]

Lines of code

---

359, 448, 509, 530, 42, 797, 162

Vulnerability details

---

The functions below transfer funds from the caller to the receiver via transferFrom(), but do not ensure that the actual number of tokens received is the same as the input amount to the transfer. If the token is a fee-on-transfer token, the balance after the transfer will be smaller than expected, leading to accounting issues. Even if there are checks later, related to a secondary transfer, an attacker may be able to use latent funds (e.g. mistakenly sent by another user) in order to get a free credit. One way to solve this problem is to measure the balance before and after the transfer, and use the difference as the amount, rather than the stated amount.

File: contracts/tOFT/BaseTOFT.sol

359:         IERC20(erc20).safeTransferFrom(_fromAddress, address(this), _amount);

File: contracts/governance/twTAP.sol

448:         rewardToken.safeTransferFrom(msg.sender, address(this), _amount);

File: contracts/option-airdrop/AirdropBroker.sol

509          _paymentToken.transferFrom(
510              msg.sender,
511              address(this),
512              discountedPaymentAmount
513:         );

File: contracts/options/TapiocaOptionBroker.sol

530          _paymentToken.transferFrom(
531              msg.sender,
532              address(this),
533              discountedPaymentAmount
534:         );

File: contracts/tokens/LTap.sol

42:          tapToken.transferFrom(msg.sender, address(this), amount);

File: contracts/Magnetar/modules/MagnetarMarketModule.sol

797:         IERC20(_token).safeTransferFrom(_from, address(this), _amount);

File: contracts/Swapper/BaseSwapper.sol

162:         IERC20(token).safeTransferFrom(msg.sender, address(this), amount);

Assessed type

---

other