[rosetta] reject negative deposit amount in extract_transfer#20238
Open
madib06ops wants to merge 1 commit into
Open
[rosetta] reject negative deposit amount in extract_transfer#20238madib06ops wants to merge 1 commit into
madib06ops wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Transfer::extract_transferparses the withdraw and deposit operation amounts asi128, then converts the deposit tou64for the transfer payload. It verifies the two amounts negate each other and that the deposit is not aboveu64::MAX, but never checks the lower bound, and-withdraw_value != deposit_valueholds for either sign orientation. A construction request carryingwithdraw.amount.value = "5"anddeposit.amount.value = "-5"passes both guards, anddeposit_value as u64wraps to 18446744073709551611.The amount flows into
aptos_stdlib::transferthroughInternalOperation::payload, so the unsigned transaction returned by/construction/payloadsdoes not match the operations that were submitted, and nothing downstream re-derives it from those operations. Swapping the one-sided comparison foru64::try_fromcovers both bounds in the conversion that actually performs the narrowing.How Has This Been Tested?
Added
test_extract_transfer_rejects_negative_depositincrates/aptos-rosetta/src/test/mod.rs, which builds the sign-flipped operation pair and asserts the extraction is rejected.Before the change:
After,
cargo test -p aptos-rosettareports 22 passed, 0 failed, so the existing transfer coverage is unchanged.Key Areas to Review
Whether the merged error message is acceptable. The over-
u64::MAXand negative cases now share oneInvalidTransferOperationsstring instead of the previous upper-bound-only wording; happy-path amounts convert exactly as before.Type of Change
Which Components or Systems Does This Change Impact?
Checklist
Note
Medium Risk
Touches Rosetta construction transfer validation; incorrect handling could still break
/construction/payloads, but the change is a narrow bounds check with a targeted test.Overview
Fixes a Rosetta construction bug where sign-flipped withdraw/deposit operations could pass validation and produce a bogus transfer amount.
Transfer::extract_transferstill requires withdraw and deposit to negate each other, but it now narrows the deposit withu64::try_frominstead of an upper-bound check plusas u64. Negative deposits (and values aboveu64::MAX) returnInvalidTransferOperationsinstead of wrapping into a huge unsigned amount that would flow into/construction/payloadsviaInternalOperation::payload.Adds
test_extract_transfer_rejects_negative_depositfor withdraw5/ deposit-5.Reviewed by Cursor Bugbot for commit d0f3d14. Bugbot is set up for automated code reviews on this repo. Configure here.