Zygo Disclosed Report

https://github.com/devZygo/zygoAuditHacken

When users opens a limit order, openLimitOrder() is called (Line 1447) In it, createLimitOrder() is called. In Line 1158, accFundingFeePerSize is set as 0.

Then when this limit order is being executed in executeLimitOrder() (Line 1531), updateFundingFeeState() is called and this updates fundingFeeState.accFeePerSize This is updated to the limit order that is being executed in openPositionForLimitOrder() (Line 1512)

However, when executeLimitOrder() calls mergePosition() in Line 1564, there is a problem. mergePosition() updates oldPosition.accFundingFeePerSize = newPosition.accFundingFeePerSize (line 1082) This would create a problem because as mentioned in the beginning, newPosition.accFundingFeePerSize is 0. (Line 1158) Funding fee is calculated using this wrong value of 0. In calculateFundingFee() (line 812), since position.accFundingFeePerSize is 0, this will result in a large funding fee for the user. Therefore causing a "loss of end-user funds", which is a in-scope critical problem. => CRITICAL

If fundingFeeState.accFeePerSize is large, all users would experience immediate liquidation due to this abnormally large funding fee as soon as his limit order has been executed and merged to a previously opened position. => CRITICAL

In addition to the user losing his funds, an anonymous attacker can do this repeatedly to continuously (and purposefully) drain bufferBalance and stop all liquidation from happening. Since liquidation for a position will fail due to require(fundingFeeGlobalState.bufferBalance >= deficitFundingFee, "Funding Fee buffer balance is insufficient"); (Line 746) All liquidation for all users will be reverted. The protocol will not be liquidating anything. => CRITICAL Attacker can use this to his advantage.

1. Open a position for a certain token type.
2. Open a limit order position for the same token type.
3. When limit order is executed, funding fee will increase.