Tadle
Tadle
DeFiFoundry
27,750 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

User may loose funds when sending native tokens using tillIn() function

0xziin

Summary

A user sending native tokens with tillIn() function in TokenManager.sol could loose funds if he sends an amount > than the amount specified in argument.

Vulnerability Details

https://github.com/Cyfrin/2024-08-tadle/blob/main/src/core/TokenManager.sol#L56

The tillIn() function checks if the amount sent is greater (or equal) to the amount specified, if not it reverts.
But if the amount sent is greater than the amount specified : msg.value > amount
the function will consider amount and not msg.value, even though msg.value is indeed sent.
=> Meaning that (msg.value - amount) will be lost for the user.

https://github.com/Cyfrin/2024-08-tadle/blob/main/src/core/TokenManager.sol#L86-L90

if (_tokenAddress == wrappedNativeToken) {
/**
* @dev token is native token
* @notice check msg value
* @dev if msg value is less than _amount, revert
* @dev wrap native token and transfer to capital pool
*/
if (msg.value < _amount) {
revert Errors.NotEnoughMsgValue(msg.value, _amount);
}
IWrappedNativeToken(wrappedNativeToken).deposit{value: _amount}();
_safe_transfer(wrappedNativeToken, capitalPoolAddr, _amount);
} else ...


We can see below that _amount is used but msg.value is sent :

IWrappedNativeToken(wrappedNativeToken).deposit{value: _amount}();
_safe_transfer(wrappedNativeToken, capitalPoolAddr, _amount);

Impact

Loss of user funds when sending native tokens.

Tools Used

VisualCode, Foundry.

Recommendations

Should check if msg.value is equal to the amount specified in argument before accepting the transaction, or accept msg.value > amount but give back the difference (msg.value - amount).

Or at least use msg.value in deposit() & _safe_transfer() instead of _amount :

IWrappedNativeToken(wrappedNativeToken).deposit{value: msg.value}();
_safe_transfer(wrappedNativeToken, capitalPoolAddr, msg.value);
Updates

Lead Judging Commences

0xnevi Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Known issue
Assigned finding tags:

[invalid] finding-TokenManager-tillin-excess

Invalid, these are by default, invalid based on codehawks [general guidelines](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#findings-that-may-be-invalid). The check implemented is simply a sufficiency check, it is users responsibility to only send an appropriate amount of native tokens where amount == msg.value when native token is intended to be used as collateral (which will subsequently be deposited as wrapped token). All excess ETH can be rescued using the `Rescuable.sol` contract. > Users sending ETH/native tokens > If contracts allow users to send tokens acc111identally.

Appeal created

0xziin Submitter
about 1 year ago
0xnevi Lead Judge
about 1 year ago
0xnevi Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Known issue
Assigned finding tags:

[invalid] finding-TokenManager-tillin-excess

Invalid, these are by default, invalid based on codehawks [general guidelines](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#findings-that-may-be-invalid). The check implemented is simply a sufficiency check, it is users responsibility to only send an appropriate amount of native tokens where amount == msg.value when native token is intended to be used as collateral (which will subsequently be deposited as wrapped token). All excess ETH can be rescued using the `Rescuable.sol` contract. > Users sending ETH/native tokens > If contracts allow users to send tokens acc111identally.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.