Skip to content

Latest commit

 

History

History
97 lines (62 loc) · 3.76 KB

027.md

File metadata and controls

97 lines (62 loc) · 3.76 KB

Fun Pear Mantis

Medium

Inconsistent EIP-712 type hash definition for Fixed6 amount in Take.sol and RelayedTake.sol will lead to signature verification failures due to nested struct propagation

Summary

Inconsistent type hash definition where Fixed6 amount is defined as int256 in the STRUCT_HASH will cause signature verification failures for users, as the nested struct propagation in RelayedTake compounds the EIP-712 type hash mismatch from the base Take contract.

Root Cause

In Take.sol, the STRUCT_HASH defines the amount field as int256 while the actual struct uses Fixed6. This type mismatch is then propagated into RelayedTake.sol STRUCT_HASH through its nested Take struct definition:

Take.sol:

https://github.com/sherlock-audit/2025-01-perennial-v2-4-update/blob/main/perennial-v2/packages/core/contracts/types/Take.sol#L9C1-L22C2

https://github.com/sherlock-audit/2025-01-perennial-v2-4-update/blob/main/perennial-v2/packages/core/contracts/types/Take.sol#L28C1-L29C10

struct Take {
    Fixed6 amount;  // Uses Fixed6
    address referrer;
    Common common;
}

bytes32 constant public STRUCT_HASH = keccak256(
    "Take(int256 amount,address referrer,Common common)"  // Defines as int256
    ...
);

RelayedTake.sol:

https://github.com/sherlock-audit/2025-01-perennial-v2-4-update/blob/main/perennial-v2/packages/periphery/contracts/CollateralAccounts/types/RelayedTake.sol#L8C1-L15C2

https://github.com/sherlock-audit/2025-01-perennial-v2-4-update/blob/main/perennial-v2/packages/periphery/contracts/CollateralAccounts/types/RelayedTake.sol#L20C1-L25C7

struct RelayedTake {
    Take take;     // Embeds Take struct
    Action action;
}

bytes32 constant public STRUCT_HASH = keccak256(
    "RelayedTake(Take take,Action action)"
    ...
    "Take(int256 amount,address referrer,Common common)"  // Propagates incorrect type
);

Internal Pre-conditions

  1. User creates a signed Take message with a Fixed6 amount value
  2. The message is processed through either:
    • Take contract directly, or
    • RelayedTake contract which nests the Take struct

External Pre-conditions

Not applicable. The vulnerability stems purely from the internal type mismatch between Fixed6 and int256 in the EIP-712 type hash definitions, and how this mismatch propagates through the nested struct implementation between Take.sol and RelayedTake.sol.

Attack Path

  1. User creates a Take with a Fixed6 amount
  2. The Fixed6 amount is internally scaled by 1e6 (BASE) as defined in Fixed6Lib
  3. When hashing for signature verification:
    • In Take: The struct uses Fixed6 (scaled) but STRUCT_HASH expects int256 (unscaled)
    • In RelayedTake: The nested Take struct inherits this mismatch, propagating it to the top-level signature verification
  4. Signature verification fails in both cases due to type mismatch and value scaling inconsistency

Impact

Users cannot execute signed Take operations as signature verifications will fail due to the type mismatch between Fixed6 and int256 in the EIP-712 domain separator. This impact is compounded because:

  1. The issue exists in both:
    • Base Take contract (direct impact)
    • RelayedTake contract (propagated impact through nested struct)
  2. All signed messages involving amounts will fail verification regardless of entry point
  3. This breaks the intended permissionless nature of the protocol for signed operations
  4. The nested struct relationship means fixing the issue requires coordinated updates to maintain consistency across both contracts

The architectural choice to nest the Take struct in RelayedTake.sol while maintaining inconsistent type definitions amplifies the impact of this vulnerability across the protocol's signature verification system.

PoC

No response

Mitigation

No response