The ModuleManager#fallback()
function is marked as payable, allowing it to accept Ether transfers. However, the current implementation does not handle msg.value
correctly when making calls to designated handlers based on the call type. This can lead to core functionality issues when the function is expected to handle incoming Ether.
The fallback function is designed to manage incoming calls using designated handlers based on the call type (either CALLTYPE_STATIC
or CALLTYPE_SINGLE
). The function does not take msg.value
into account, causing the functionality to break when there is Ether attached to the call.
Here is the original fallback function:
The issue lies in the omission of msg.value
when making the call. For CALLTYPE_SINGLE
, the value should be forwarded, whereas CALLTYPE_STATIC
should not handle Ether transfers.
The core functionality of the fallback mechanism is broken when msg.value
is expected to be transferred with the call. This can lead to significant issues, including:
Failure to execute intended actions if Ether is required by the handler.
Potential loss of Ether if the handler does not properly handle the transfer.
Inconsistent behavior of the fallback function, leading to security vulnerabilities and system instability.
Manual code review
To resolve the issue, update the fallback function to correctly handle msg.value
for CALLTYPE_SINGLE
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.