You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Vulnerability Details:
Even after fixing the dynamic size allocation, there is a bug where retData is still pre-allocated to a fixed size (2 * 32 bytes). This allocation should be done dynamically based on returndatasize() after the call is made. The return data (retData) is pre-allocated to maxReturnDataBytes (64 bytes).
This fixed allocation could lead to inefficient memory usage and potential issues if the actual return data is much smaller or larger. Proof Of Code
Impact:
Inefficiency: Allocating more memory than needed wastes gas and can potentially cause problems if not managed properly.
Potential Data Truncation: The current allocation doesn't handle return data that exceeds 64 bytes.
Tool Used
Manual
Recommendation
Allocate memory for retData dynamically after determining the size using returndatasize():
I am very skeptical about how to judge your submission.
You have found the problem part, but you didn't point out the exact impact and based on your description, you don't understand the purpose behind the contract functionality. Truncating the response is part of the main functionality, because we want to protect from gas bombs. #34 best describes the issue, the root and the impact.
I've decided to split the reward between the two submissions. Although yours was the first, the description was lacking in detail and main impact.
I am very skeptical about how to judge your submission. You have found the problem part, but you didn't point out the exact impact and based on your description, you don't understand the purpose behind the contract functionality. Truncating the response is part of the main functionality, because we want to protect from gas bombs. #34 best describes the issue, the root and the impact.
I've decided to split the reward between the two submissions. Although yours was the first, the description was lacking in detail and main impact.
Thank you for judging fairly. i appreciate your decision.
Severity: Medium
Vulnerability Details:
Even after fixing the dynamic size allocation, there is a bug where retData is still pre-allocated to a fixed size (2 * 32 bytes). This allocation should be done dynamically based on returndatasize() after the call is made. The return data (retData) is pre-allocated to maxReturnDataBytes (64 bytes).
This fixed allocation could lead to inefficient memory usage and potential issues if the actual return data is much smaller or larger.
Proof Of Code
Impact:
Inefficiency: Allocating more memory than needed wastes gas and can potentially cause problems if not managed properly.
Potential Data Truncation: The current allocation doesn't handle return data that exceeds 64 bytes.
Tool Used
Manual
Recommendation
Allocate memory for retData dynamically after determining the size using returndatasize():
This approach ensures that the contract efficiently handles return data of any size without risk of truncation or inefficiency.
The text was updated successfully, but these errors were encountered: