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
{{ message }}
This repository has been archived by the owner on Jan 7, 2024. It is now read-only.
sherlock-admin opened this issue
Jul 3, 2023
· 0 comments
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
Lack of scaling the decimals precision in the AccountFacet#depositAndAllocateForPartyB(), which lead to a misaccounting
Summary
Within the AccountFacet#depositAndAllocateForPartyB(), the amount scaled to 1e18 decimals precision is supposed to be assigned into the AccountFacetImpl#allocateForPartyB().
However, within the AccountFacet#depositAndAllocateForPartyB(), the amount, which is 1e6 decimals (Not scaled), would be assigned into the AccountFacetImpl#allocateForPartyB() as it is.
This lead to a misaccounting that the amount subtracted from the balances storage in the AccountFacetImpl#allocateForPartyB() would be 1e12 times smaller than the actual amount.
Within the AccountFacet#depositAndAllocateForPartyB() above, the amount assigned as a parameter would be 1e6 decimals precision.
And then, within the AccountFacet#depositAndAllocateForPartyB() above, the AccountFacetImpl#depositForPartyB() and the AccountFacetImpl#allocateForPartyB() would be called. The amount assigned into each function is supposed to be like this:
The amount that is assigned into the AccountFacetImpl#depositForPartyB() is supposed to be 1e6 decimals precision.
The amount that is assigned into the AccountFacetImpl#allocateForPartyB() is supposed to be 1e18 decimals precision.
However, the amount assigned into the AccountFacetImpl#allocateForPartyB() would not be scaled to 1e18 decimals precision. (Instead, the amount that is 1e6 decimals precision would be assigned into the AccountFacetImpl#allocateForPartyB() as it is)
This vulnerability would always be caused every single time when the AccountFacet#depositAndAllocateForPartyB() would be called. Thus, this severity is marked as "High".
Within the AccountFacet#depositAndAllocateForPartyB(), consider assigning the amount scaled to 1e18 into the AccountFacetImpl#allocateForPartyB() like this:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
0xmuxyz
high
Lack of scaling the decimals precision in the AccountFacet#
depositAndAllocateForPartyB()
, which lead to a misaccountingSummary
Within the AccountFacet#
depositAndAllocateForPartyB()
, theamount
scaled to1e18
decimals precision is supposed to be assigned into the AccountFacetImpl#allocateForPartyB()
.However, within the AccountFacet#
depositAndAllocateForPartyB()
, theamount
, which is1e6
decimals (Not scaled), would be assigned into the AccountFacetImpl#allocateForPartyB()
as it is.This lead to a misaccounting that the
amount
subtracted from thebalances
storage in the AccountFacetImpl#allocateForPartyB()
would be1e12
times smaller than the actual amount.Vulnerability Detail
Within the AccountFacet#
depositAndAllocateForPartyB()
, theamount
would be assigned as a parameter.Then, the AccountFacetImpl#
allocateForPartyB()
would be called and theamount
would be assigned into there like this:https://github.com/sherlock-audit/2023-06-symmetrical/blob/main/symmio-core/contracts/facets/Account/AccountFacet.sol#L79
Within the AccountFacetImpl#
allocateForPartyB()
, theamount
would be subtract from thebalances
storage like this:(NOTE:The
amount
assigned into thebalances
storage below is supposed to be1e18
decimals precision)https://github.com/sherlock-audit/2023-06-symmetrical/blob/main/symmio-core/contracts/facets/Account/AccountFacetImpl.sol#L130
Within the AccountFacet#
depositAndAllocateForPartyB()
above, theamount
assigned as a parameter would be1e6
decimals precision.And then, within the AccountFacet#
depositAndAllocateForPartyB()
above, the AccountFacetImpl#depositForPartyB()
and the AccountFacetImpl#allocateForPartyB()
would be called. Theamount
assigned into each function is supposed to be like this:amount
that is assigned into the AccountFacetImpl#depositForPartyB()
is supposed to be1e6
decimals precision.amount
that is assigned into the AccountFacetImpl#allocateForPartyB()
is supposed to be1e18
decimals precision.However, the
amount
assigned into the AccountFacetImpl#allocateForPartyB()
would not be scaled to1e18
decimals precision. (Instead, theamount
that is1e6
decimals precision would be assigned into the AccountFacetImpl#allocateForPartyB()
as it is)Impact
This lead to a misaccounting that the
amount
, which subtracted from thebalances
storage in the AccountFacetImpl#allocateForPartyB()
, would be1e12
times smaller than the actual amount.https://github.com/sherlock-audit/2023-06-symmetrical/blob/main/symmio-core/contracts/facets/Account/AccountFacetImpl.sol#L130
This vulnerability would always be caused every single time when the AccountFacet#
depositAndAllocateForPartyB()
would be called. Thus, this severity is marked as "High".Code Snippet
Tool used
Manual Review
Recommendation
Within the AccountFacet#
depositAndAllocateForPartyB()
, consider assigning the amount scaled to1e18
into the AccountFacetImpl#allocateForPartyB()
like this:Duplicate of #222
The text was updated successfully, but these errors were encountered: