Closed sherlock-admin3 closed 4 months ago
This issue is actually invalid, the deployed storage and the v2.2 storage are the same, see the diff here: https://github.com/equilibria-xyz/perennial-v2/pull/263/files#diff-8f246f534b2e8eff82827f965b322065dcb8de7145a0950338032fcf24cd1fee
as well as the latest impl deployment here: https://arbiscan.io/address/0x31e1d5c8e8646cd581a4d930b3e5bfe12069c189#code
I've compared against the previously audited version which I've reviewed fixes for: https://github.com/equilibria-xyz/perennial-v2/pull/184
As this doesn't seem to be the correct code from which it's being migrated, then I believe this issue is invalid. But it's best to specify the exact version of the code which is being migrated in the future to avoid misunderstandings like this.
Escalate
Have a check on this too, looks like the sponsor is correct
This issue is actually invalid, the deployed storage and the v2.2 storage are the same, see the diff here: https://github.com/equilibria-xyz/perennial-v2/pull/263/files#diff-8f246f534b2e8eff82827f965b322065dcb8de7145a0950338032fcf24cd1fee
as well as the latest impl deployment here: https://arbiscan.io/address/0x31e1d5c8e8646cd581a4d930b3e5bfe12069c189#code
Escalate
Have a check on this too, looks like the sponsor is correct
This issue is actually invalid, the deployed storage and the v2.2 storage are the same, see the diff here: https://github.com/equilibria-xyz/perennial-v2/pull/263/files#diff-8f246f534b2e8eff82827f965b322065dcb8de7145a0950338032fcf24cd1fee
as well as the latest impl deployment here: https://arbiscan.io/address/0x31e1d5c8e8646cd581a4d930b3e5bfe12069c189#code
You've created a valid escalation!
To remove the escalation from consideration: Delete your comment.
You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.
Unfortunately, this wasn’t caught during the competition, judging and preliminary judging phase by all parties, which should have been asked and clarified regarding the latest implementation deployed. So agree with the escalation to invalidate the issue.
@arjun-io I presume this also apply to base as well, given you linked to only a arbitrum address for the implementation contract.
Planning to accept escalation and invalidate issue. As no one had any context on the right reference contract. We should take the sponsors current opinion.
Result: Invalid Has Duplicates
panprog
high
MultiInvoker's stored TriggerOrders are not migrated to new format, potentially causing huge interface fees charged to users.
Summary
TriggerOrder
struct which is used to store orders inMultiInvoker
has changed in v2.3 compared to v2.2, however, there is no migration process for these orders mentioned in the Migration Guide, meaning there might be problems with existing v2.2 orders, in particular:interfaceFeeAmount
is now in unused area (meaning interfaces won't receive fees for these orders)interfaceFeeUnwrap
collides with the new version'sinterfaceFeeAmount1
(meaning that if existing order hadinterfaceFeeUnwrap = true
, the new version will handle it as a 2^40 fee value (in UFixed6 format 2^40 = ~1.1M USDC), charging huge interface fee from unsuspecting users when the order executes). This will likely revert for insufficient funds to pay the fee, but if the user does have 1.1M+ collateral, this huge amount will be charged to interface fee for order exectution.interfaceFeeUnwrap
are in the previously unallocated area, meaning it will befalse
for all previous orders, potentially creating problems/funds loss for interfaces which can't handle DSU token and needed underlying (USDC) instead.Vulnerability Detail
Previous version's
TriggerOrder
:New version's
TriggerOrder
:Notice the @audit remarks in the code. When existing v2.2 orders will be executed in v2.3 code, the overlapping fields in slot1 will cause incorrect values for these orders.
Impact
For existing orders with interface fee specified:
interfaceFeeUnwrap
was set totrue
, fee charged will be 2^40 (==~1.1M USDC), unexpected fee amount for the user. Additionally,interfaceFeeUnwrap
will be treated asfalse
, thus interface will receive this fee of 2^40 as DSU rather than underlying (USDC).interfaceFeeUnwrap
was set tofalse
, fee charged will be 0, fee funds lost by the interfaceFee account which expected to receive it.Code Snippet
Previous version of
TriggerOrder
: https://github.com/equilibria-xyz/perennial-v2/blob/7e60e69de9a613bfb449dc976801a000daa72aa4/packages/perennial-extensions/contracts/types/TriggerOrder.sol#L18-L31New version of
TriggerOrder
: https://github.com/sherlock-audit/2024-02-perennial-v2-3/blob/main/perennial-v2/packages/perennial-extensions/contracts/types/TriggerOrder.sol#L19-L39Tool used
Manual Review
Recommendation
Possible solutions:
TriggerOrder
format to avoid fields collision (and carry over all values from existing orders)