Cross-Instruction State Desync

Overview

The cross-instruction state desync detector identifies vulnerabilities where programs with multiple instructions in a transaction modify shared accounts and later instructions assume state changes from earlier instructions are atomic and cannot be manipulated. Attackers can craft instruction sequences that violate these assumptions, leading to double-spending, state corruption, and privilege escalation.

For remediation guidance, see Cross-Instruction State Desync Remediation.

Why This Is an Issue

Solana transactions can contain multiple instructions that execute sequentially. If instruction 1 writes state that instruction 2 reads, an attacker can insert their own instruction between them that modifies the shared account, desynchronizing the expected state flow. This is particularly dangerous in DeFi, gaming, and governance programs.

How to Resolve

Before (Vulnerable)

// Instruction 1: sets state
pub fn prepare(ctx: Context<Prep>) -> Result<()> {
    ctx.accounts.state.prepared = true;
    ctx.accounts.state.amount = calculated_amount;
    Ok(())
}

// Instruction 2: assumes state from instruction 1
pub fn execute(ctx: Context<Exec>) -> Result<()> {
    require!(ctx.accounts.state.prepared, NotPrepared);
    transfer(ctx.accounts, ctx.accounts.state.amount)?;
    Ok(())
}

After (Fixed)

// Fixed: validate state freshness with nonce
pub fn execute(ctx: Context<Exec>, expected_nonce: u64) -> Result<()> {
    require!(ctx.accounts.state.prepared, NotPrepared);
    require!(ctx.accounts.state.nonce == expected_nonce, StaleState);
    transfer(ctx.accounts, ctx.accounts.state.amount)?;
    ctx.accounts.state.prepared = false;  // Clear after use
    ctx.accounts.state.nonce += 1;
    Ok(())
}

Example JSON Finding

{
  "detector": "cross-instruction-state-desync",
  "severity": "high",
  "confidence": 0.65,
  "message": "Account written in one handler and read in another without state validation",
  "location": { "function": "execute", "block": 0, "statement": 2 }
}

Detection Methodology

1. State write tracking: Identifies account data writes in instruction handlers.
2. State read tracking: Identifies account data reads in other instruction handlers.
3. Validation gap detection: Flags read-after-write patterns without state validation.
4. Instruction ordering analysis: Checks for ordering assumptions that attackers can violate.

Limitations

False positives: Single-instruction programs that never have cross-instruction state. False negatives: State desync through accounts not shared between handlers.

Related Detectors

• Cross-Program State — CPI state issues
• Cross-Contract Consistency — multi-account consistency

References

• Solana — Transactions
• CWE-362: Concurrent Execution Using Shared Resource