Reentrancy Analysis

Skill: REENTRANCY_ANALYSIS

Trigger: REENTRANCY flag detected (dynamic dispatch, closures, dispatchable FA, function values) Used by: Breadth agents, depth-state-trace Covers: Cross-module reentrancy via closures, dispatchable FA hook reentrancy, direct/indirect reentrancy, resource lock gaps

Purpose

Audit reentrancy vectors in Aptos Move. Historically, Move's linear type system and static dispatch prevented reentrancy. Post Move 2.2, function values (closures) and dispatchable FungibleAsset hooks introduce dynamic dispatch, creating reentrancy surfaces analogous to EVM callbacks but with different mechanics and mitigations.

Background: Aptos Reentrancy Model

Pre Move 2.2: No dynamic dispatch. All function calls are statically resolved at compile time. Reentrancy was architecturally impossible (no callbacks, no external calls to untrusted code).

Post Move 2.2: Two reentrancy vectors exist:

1. Function values / closures: |arg| { body } syntax allows passing executable code as parameters. A module calling a user-supplied closure can be reentered.
2. Dispatchable FungibleAsset hooks: withdraw, deposit, and derived_balance hooks execute external module code during FA operations. This is framework-level dynamic dispatch.

#[module_lock]: Prevents INDIRECT reentrancy (cross-module reentry into the locked module). Does NOT prevent DIRECT reentrancy (closure calling back into the same module's function within the same execution frame).

Methodology

STEP 1: Dynamic Dispatch Point Inventory

Find ALL uses of dynamic dispatch in the audited modules:

1a. Function Values and Closures

MANDATORY SEARCH: Grep all .move files for:

1. | followed by parameter patterns (closure syntax: |x| { ... }, |x, y| { ... })
2. Function types in signatures (e.g., callback: |u64| -> u64, FunctionValue)
3. move | (move closures that capture variables)
4. Functions that accept function-typed parameters

1b. Dispatchable FA Hooks

MANDATORY SEARCH: Grep for:

1. dispatchable_fungible_asset module usage
2. register_dispatch_functions or equivalent hook registration
3. withdraw_with_*, deposit_with_* function patterns
4. derived_balance implementations

STEP 2: Module Lock Analysis

For each module containing dynamic dispatch points:

CRITICAL DISTINCTION:

• #[module_lock] = YES: Indirect reentrancy blocked (Module A -> closure -> Module A's function). Direct reentrancy still possible (within same function frame, closure calls same module's public function via friend or inline).
• #[module_lock] = NO: Both direct and indirect reentrancy possible.

Check: For each module WITHOUT #[module_lock]:

1. Does it have any dynamic dispatch points (from Step 1)?
2. If YES: cross-module reentrancy is possible - trace all paths.

STEP 3: Third-Party Resource Lock Bypass

If the audited module stores data in a third-party resource abstraction:

Pattern: Module A stores its accounting data in a SmartTable (from aptos_std). aptos_std may have #[module_lock]. But this lock only prevents reentry into aptos_std - it does NOT prevent reentry into Module A. An attacker can reenter Module A while Module A's SmartTable operation is in progress.

Check: Does the protocol rely on a third-party module's lock for its own reentrancy protection? If YES -> FINDING.

STEP 4: State Consistency Analysis (Check-Effect-Interaction)

For each dynamic dispatch point identified in Step 1:

4a. Pre-Dispatch State Snapshot

4b. Reentrancy Impact Trace

For each dispatch point where state is modified before dispatch:

1. Function entry: Read state S1 (e.g., user_balance = 100)
2. Modify state: S1 partially updated (e.g., user_balance -= 50, but total_supply not yet updated)
3. Dynamic dispatch: closure/hook executes
4. REENTRY: Attacker calls back into same module
5. Reentrant call reads: S1 (modified) - sees user_balance = 50
6. Reentrant call reads: S2 (NOT yet modified) - sees stale total_supply = 1000 (should be 950)
7. Inconsistency: S1 and S2 are out of sync
8. Original execution resumes: modifies S2 (total_supply = 950)
9. Impact: [describe what the attacker gained]

Key question for each dispatch point: Is there ANY pair of state variables (S1, S2) where S1 is updated before dispatch but S2 is updated after? If YES, the reentrant call sees an inconsistent state.

STEP 5: Dispatchable FA Specific Reentrancy

If the protocol uses dispatchable FungibleAsset:

5a. Withdraw Hook Reentrancy

// Framework calls this DURING withdrawal:
fun withdraw_hook(store: Object<FungibleStore>, amount: u64, ...) {
    // This code runs AFTER the framework has decided to withdraw
    // but potentially BEFORE the calling module's post-withdrawal logic

    // Can this hook call back into the protocol?
    // What state has been partially modified at this point?
}

Trace: What is the call stack at the point the withdraw hook fires?

1. Protocol function (e.g., redeem())
2. Framework fungible_asset::withdraw()
3. Hook: module::withdraw_hook()
4. Hook can call: ??? (any public function accessible)