The VaultReader contract previously contained integer overflow and underflow risks in the calculation of netValue in getPositionInfo() function. The vulnerabilities arose from unchecked arithmetic operations on position collateral, fees, and token prices. This report outlines the identified issues, their impact, and the implemented fixes to ensure safe arithmetic operations using OpenZeppelin’s SafeMath library.
The affected code segment involved calculations such as:
Issues Identified:
1. Multiplication Overflows: If collateralAmount or shortTokenPrice.min were too large, the multiplication could exceed the maximum uint256 value (2^256 - 1), leading to an overflow.
2. Subtraction Underflows: If the sum of all subtracted fees exceeded the total collateral, an underflow could occur, potentially causing unintended behavior.
3. Negative PnL Handling: Since PnL can be negative, incorrect conversion from int256 to uint256 could lead to unintended arithmetic results.
• Overflow or underflow in these calculations could result in incorrect values for netValue, leading to incorrect risk calculations, improper liquidations, or manipulated position sizes.
• If exploited, malicious actors could prevent liquidation of undercollateralized positions or manipulate displayed PnL values, creating an economic attack vector within the system.
• Slither (Static analysis) – Detected potential overflow and underflow risks.
• Foundry/Hardhat Tests – Confirmed calculations under extreme values.
To mitigate these risks, SafeMath from OpenZeppelin was used for secure arithmetic operations. The updated safe version of the netValue calculation is:
Improvements Implemented:
✅ Multiplication safety – Using .mul() from SafeMath to prevent overflows.
✅ Subtraction safety – Using .sub() from SafeMath to avoid underflows.
✅ Proper PnL handling – Explicit conversion of int256 to uint256 with validation.
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.