Tadle

Tadle
DeFi
30,000 USDC
View results
Submission Details
Severity: low
Invalid

excess eth or incorrect eth being sent are not rejected by the tillIn function

Summary

When the protocol want a deposit to happen it calls the tillIn function, it does not reject extra eth which is more than the value sent or eth sent when the tokenAddress is an erc-20 token, which may have unintended consequences

Vulnerability Details

if (msg.value < _amount) {
revert Errors.NotEnoughMsgValue(msg.value, _amount);
}
IWrappedNativeToken(wrappedNativeToken).deposit{value: _amount}();
_safe_transfer(wrappedNativeToken, capitalPoolAddr, _amount);
} else {
/// @notice token is ERC20 token
_transfer(
_tokenAddress,
_accountAddress,
capitalPoolAddr,
_amount,
capitalPoolAddr
);
}
//@audit M-09 There should be a implementation to revert either when the token being sent is an erc 20 and msg.value is greater than zero, or when execess funds of msg.value are sent to prevent loss of funds of users

This snippet of code from the tillIn function checks if the msg.value is enough to cover the amount being deposited, but it does not check if it is more and also if the token address is an erc token and a msg.value is also sent together, in both cases, eth are lost and it is imperative that users don't loose funds when trying to deposit

Impact

Since deposit may occur by users sending tx directly to the smart contract, extra eth sent along or incorrect eth sent with erc20 tokens should either be refunded or should be prevented from outright being able to deposit

Tools Used

manual review

Recommendations

A check to make sure the exact amount of eth required should be deposited , and a check inside the else statement that checks if you are sending eth if the tokenAddress is a erc20 tokens, to revert or to refund the amount back to the caller

Updates

Lead Judging Commences

0xnevi Lead Judge 10 months 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.