# Some actions are allowed on partyB when corresponding partyA is liquidated allowing to steal all protocol funds

deallocateForPartyB/transferAllocation lack partyA-liquidation checks, letting a partyB deallocate inflated balance mid-liquidation and drain all protocol funds.

- Payout: Contest reward
- Severity: medium
- Program: Symmetrical
- Credited: panprog
- Disclosed: 2023-06-05
- Write-up quality: 8/10
- Original: https://github.com/sherlock-audit/2023-06-symmetrical-judging/issues/189
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-symmetrical%3AM-8
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:chained technique:source-review vuln:accounting-error vuln:business-logic vuln:signature-replay

**Target:** Symmio-core AccountFacet / AccountFacetImpl (deallocateForPartyB, transferAllocation)
**Root cause:** deallocateForPartyB and transferAllocation do not check whether the counterparty partyA is mid-liquidation, so partyB can deallocate an allocatedBalance that was inflated by liquidating only the profitable-for-partyB position, using a stale singleUpnlSig (partyB nonce unchanged by position liquidation).
**Steps:**
1. Control partyA, partyB, and liquidator roles.
2. Open two opposite positions between partyA and partyB with openPrice far from market, slightly different sizes so partyA becomes liquidatable on price move.
3. Call `liquidatePartyA(partyA, singleUpnlSig(-100))` and `setSymbolsPrice(partyA, priceSig, -100, 1100)`.
4. Capture `previousSig = singleUpnlSig(+100)` for partyB while partyB is in small profit.
5. Liquidator calls `liquidatePositionsPartyA(partyA, [1])` liquidating only the loss-for-partyA/profit-for-partyB position, inflating partyB allocatedBalance; partyB nonce unchanged.
6. Call `deallocateForPartyB(1530, partyA, previousSig)` (or transferAllocation then deallocate) with the stale signature.
7. Call `withdraw(balance)` to drain protocol collateral.
**How found:** Code review of AccountFacet/AccountFacetImpl noting missing liquidation-status checks on deallocateForPartyB and transferAllocation, then reasoning about the multi-step liquidation flow and that liquidatePositionsPartyA increases partyB allocatedBalance without bumping partyB nonce, making a pre-liquidation signature reusable.
**Exploitation:** Attacker opens offsetting positions, triggers partyA liquidation, has the controlled liquidator liquidate only the position profitable to partyB, inflating partyB's allocatedBalance while keeping the stale upnl signature valid, then deallocates and withdraws more than the protocol holds.
**Escalation:** Chained with liquidator's ability to pick which partyA positions to liquidate, and nonce not changing on position liquidation, to inflate balance beyond total protocol deposits.
**Insight:** In multi-step liquidation designs, check every state-mutating partyB/partyA action against in-progress liquidation status, and verify whether liquidation steps change the nonce/signature domain — a stale signed upnl can be replayed after balance inflation.