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

Missing Refund of Excess Ether in tillIn Function

heaven1024

Summary

The tillIn function in the TokenManager contract does not handle cases where the msg.value exceeds the _amount parameter. This can lead to a situation where excess Ether sent by the caller is not returned, potentially causing a loss of funds for the user.

Vulnerability Details

In the tillIn function, when the msg.value is greater than _amount, the function does not return the excess Ether to the caller. This is an issue because if a user sends more Ether than required for the transaction, the excess amount is not refunded, resulting in a loss of the excess funds.

The specific code segment that demonstrates this issue is:

if (_tokenAddress == wrappedNativeToken) {
...
if (msg.value < _amount) {
revert Errors.NotEnoughMsgValue(msg.value, _amount);
}
...

After this check, the function proceeds to deposit the exact _amount of Ether but does not handle the scenario where msg.value is greater than _amount.

Impact

Users who interact with the tillIn function may accidentally send more Ether than required. Since the function does not return the excess Ether, users may lose these additional funds. This could lead to a poor user experience and financial loss for users who are unaware of this behavior.

Tools Used

Manual code review

Recommendations

Refund Excess Ether: Modify the tillIn function to handle cases where msg.value is greater than _amount. You should return any excess Ether to the caller after processing the deposit. For example:

...
if (msg.value < _amount) {
revert Errors.NotEnoughMsgValue(msg.value, _amount);
}
uint256 excessAmount = msg.value - _amount;
if (excessAmount > 0) {
payable(msg.sender).transfer(excessAmount);
}
...
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.

Support

FAQs

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