# It's possible to reset primaryCredit and secondaryCredit for insurance account

Anyone could call handleBadDebt on the insurance account once its credit went negative, zeroing its primaryCredit and secondaryCredit and breaking insurance accounting.

- Payout: Contest reward
- Severity: medium
- Program: Jojo
- Credited: GalloDaSballo
- Disclosed: 2023-04-11
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-04-jojo-judging/issues/159
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-04-jojo%3AM-3
- Tags: domain:web3 impact:integrity kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Perpetual/insurance accounting contract (JOJOExternal.handleBadDebt)
**Root cause:** handleBadDebt lacks a guard against liquidatedTrader == state.insurance; when the insurance account itself is unsafe (negative primaryCredit after absorbing bad debt), calling it moves its own credit onto itself then zeroes it.
**Steps:**
1. Cause insurance account primaryCredit to go negative via bad-debt handling of liquidated accounts
2. Confirm Liquidation._isSafe(state, insurance) == false
3. Call `JOJOExternal.handleBadDebt(state, insurance)`
4. Function adds primaryCredit/secondaryCredit to insurance then sets them to 0, wiping the values
**How found:** Code review of handleBadDebt: noticed no check preventing the insurance address from being passed as liquidatedTrader, and that the self-referential add-then-zero resets state.
**Exploitation:** Any external caller invokes handleBadDebt with the insurance address as liquidatedTrader once it is unsafe; the self-add then zero-out resets insurance credit balances, corrupting insurance accounting.
**Insight:** When a function moves a victim's balances into a shared pool address, check whether that pool address can itself be passed as the victim — self-referential transfers followed by zeroing silently destroy state.