fix(derivation): guard against blockCount underflow on malformed batches

[curryxbo]

Summary

Re-apply the underflow guard in BatchInfo.ParseBatch (originally landed as commit aae2213 on this branch and reverted by 82e7062 without replacement). Addresses audit feedback on PR #935.

The bug

In node/derivation/batch_info.go::ParseBatch, both block-count derivation paths subtract two attacker-controllable uint64 values without bounds checking:

// V0 -> V1+ transition
blockCount = batch.LastBlockNumber - startBlock.Number + 1

// V1+
blockCount = batch.LastBlockNumber - parentBatchBlock

batch.LastBlockNumber is read directly from L1 calldata; the L1 Rollup contract does not constrain its relationship to the parent batch. A malformed batch with LastBlockNumber < parentBatchBlock (or LastBlockNumber < startBlock.Number in the V0→V1 path) underflows blockCount to a near-2^64 value.

Downstream, bcLen := blockCount * 60 wraps modulo 2^64. For specific attacker-chosen LastBlockNumber values, bcLen wraps to a small number, the boundary check if uint64(len(batchBytes)) < bcLen passes spuriously, and the subsequent loop (for i := 0; i < int(blockCount); i++) iterates against rawBlockContexts[i*60 : i*60+60] and panics with a slice-out-of-range. Net effect: a single malformed L1 commit batch crashes every honest derivation node simultaneously.

The fix

Reject the malformed batch with a clear error before the subtraction, in both paths:

• V0 → V1+ transition: error if batch.LastBlockNumber < startBlock.Number
• V1+: error if batch.LastBlockNumber < parentBatchBlock

Asymmetry between the two guards is intentional — V0→V1 has a + 1 so equality represents a valid 1-block batch; V1+ does not, so equality represents an empty (0-block) batch which does not panic and is therefore out of scope for this PR.

10 lines, no behavioral change on well-formed batches.

Why this is being re-applied

Commit aae2213 originally landed this fix on feat/multi_batch on 2026-05-11. Commit 82e7062 reverted it ~1h later with a one-line message and no replacement implementation; the underflow path has been live on the branch ever since. Audit review on PR #935 flagged the same panic vector independently, so the fix is going back in.

Test plan

• Local go build ./... in node/
• CI passes
• Manual: construct a fake RPCRollupBatch with LastBlockNumber < parent.LastBlockNumber() in unit context and confirm ParseBatch returns the new error rather than panicking. (Regression test deliberately not bundled in this PR — kept scope minimal at the request of the reviewer; tracked separately.)

🤖 Generated with Claude Code

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.

_{Tip: disable this comment in your organization's Code Review settings.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 84cf70cb-7d1d-4e18-becb-e3ab4f888f5b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/derivation-blockcount-underflow

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}