Liquidity Management

Summary

A vulnerability exists in the PerpetualVault::_withdraw function, specifically in the calculation of the Profit and Loss (PnL) deduction. The issue arises due to the use of gmxReader.getPositionInfo with an incorrect parameter usePositionSizeAsSizeDeltaUsd set to true that results in the PnL being calculated for the entire position rather than just for the user's share. This leads to an excessive deduction from the user's withdrawal amount, reducing their funds unfairly.

Vulnerability Details

The affected code is in the PerpetualVault::_withdraw function, specifically the part:

• The function vaultReader.getPnl:

internally calls gmxReader.getPositionInfo with the last parameter usePositionSizeAsSizeDeltaUsd set to true.

• This setting computes the PnL for the entire position rather than just for sizeDeltaUsd.

• As a result, pnl in PerpetualVault::_withdraw represents the total loss of the entire position instead of only the user's portion.

• This incorrect calculation leads to an unfair reduction in the user's withdrawal amount (collateralDeltaAmount is less than it should be).

Impact

• Users may receive significantly less funds than they actually hold when withdrawing.

• A key invariant of the protocol, Depositor Share Value Preservation, is broken. Losses may not be distributed proportionally based on share ownership.

• This issue can cause financial losses and unfair withdrawals.

Example:

Assume:

• User A has 20 shares

• User B has 20 shares (same as user A)

• totalShares = 100

• collateralAmount = 20,000

• pnl = -$500 (the total PnL for the position)

• shortTokenPrice.max = 1

User A Withdraws First (While Position is Still Open)

Using the calculation in PerpetualVault::_withdraw, User A’s collateralDeltaAmount is (ignoring feeAmount):

What they should actually get (when pnl is scaled properly to their share proportion):

Discrepancy: 400 loss for User A

User B Withdraws After the Position Closes

After User A withdraws:

• collateralAmount updates to (Subtracting User A’s collateral and pnl ):

  20,000 - 3,500 - 500 = 16,000

Now User B withdraws their share of the remaining collateral following PerpetualVault::_withdraw for a closed position:

Final Discrepancy

• **User A received: 3,500 **

• **User B received: 4,000 **

• Difference: 500

Because the loss was not distributed proportionally, User A lost 400 more than they should have, while User B benefited by receiving a higher amount than they should.

• In addition, since the whole position pnl is subtracted in

collateralDeltaAmount may become negative causing the function to revert.

Tools Used

Manual Review

Recommendations

Two possible ways of mitigating the vulnerability are:

1. Modify gmxReader.getPositionInfo Call

   • Set the last parameter to false when calling gmxReader.getPositionInfo inside vaultReader.getPnl.

   PositionInfo memory positionInfo = gmxReader.getPositionInfo(

   address(dataStore),

   referralStorage,

   key,

   prices,

   sizeDeltaUsd,

   address(0),

   - true

   + false // Ensure PnL is calculated for the specific withdrawal amount

   );

2. Scale PnL Deduction in _withdraw Function

   • Adjust pnl by multiplying it with shares / totalShares before deducting from collateralDeltaAmount.

   int256 pnl = vaultReader.getPnl(curPositionKey, prices, sizeDeltaInUsd);

   + int256 deltaPnl = (pnl * uint256(shares)) / uint256(totalShares);

   if (pnl < 0) {

   - collateralDeltaAmount = collateralDeltaAmount - feeAmount - uint256(-pnl) / prices.shortTokenPrice.max;}

   + collateralDeltaAmount = collateralDeltaAmount - feeAmount - uint256(-deltaPnl) / prices.shortTokenPrice.max;}

   ​