[audit][low] State sync commits subtree batches before final root verification

[QuantumExplorer]

Created from a Codex audit of grovedb. No code changes were made as part of the audit.

Summary

Replication state sync flushes completed subtree batches before the final app-hash check.

Impact / failure scenario

A malicious or inconsistent peer can send a snapshot that fails final verification after earlier subtrees have already been committed, leaving partially durable state even though commit_session returns an error.

References

• grovedb/src/replication/state_sync_session.rs:251
• grovedb/src/replication/state_sync_session.rs:263
• grovedb/src/replication/state_sync_session.rs:290
• grovedb/src/replication/state_sync_session.rs:590

Suggested fix

Stage restored state in a temporary DB/namespace or keep all subtree writes uncommitted until final root verification succeeds.

Suggested tests

Use subtrees_batch_size = 1, corrupt a later chunk/final hash, and assert the destination DB remains unchanged after failure and reopen.

---

September 2026 audit addendum — S06

Audit group: S06. Classification: correctness. Provisional severity: medium.

Audit addendum for #679, with #775 retained as a same-root related report. Provisional static review of snapshot 2fa0f133 confirms that the session can durably commit completed subtree groups before the complete snapshot has been accepted. This addendum does not claim that current develop remains affected or replace the original issue's severity assessment.

The expected failure-atomicity contract is that a rejected or incomplete synchronization cannot be published as a complete destination. At configured subtree boundaries, the session commits its previous transaction and continues using a new transaction. Further discovery, response processing and final complete-session/root checks occur afterward. A later failure or interruption cannot roll back groups already committed by the earlier transaction.

Individual nonempty chunks are still checked against expected commitments, and final root mismatch is still returned as an error. This report does not establish successful acceptance of an arbitrary root. Its material consequence is persistent partial destination state after an unsuccessful operation. Security exposure requires the additional application behavior of reusing or publishing that failed destination. Restoring into private disposable staging and promoting only after complete verification contains that consequence.

Keep rollback authority for the entire snapshot or stage it in an isolated destination that is promoted only after all verification succeeds. If durable incremental staging is necessary, record incomplete status and prevent publication until completion. Define cleanup and recovery for cancellation, interruption and ordinary late validation failures, not only the final hash comparison.

The supplied inventory shows that closed PR #735 was unmerged; open PR #840 explicitly proposes removal of intermediate commits. Those proposals are relevant remediation context, not proof of a fix in this audited snapshot. Independent records rated this mechanism medium and low. Medium here denotes correctness priority for durable partial state, with deployment-dependent security impact stated separately. No runtime transaction, failure, cancellation or reopen test was executed during this static review.

Validation to complete

• Verify a cancelled or ordinarily rejected multi-group restore does not change the published destination.
• Check complete snapshot promotion occurs only after all structural and root obligations pass.
• If staging persists across restart, verify incomplete status prevents publication and supports documented recovery.

Limits and existing work

• PR feat(replication)!: complete V1 state sync and bounded-memory restore #840 is proposed; fix(replication): keep state sync restore atomic until commit #735 is closed unmerged in supplied inventory.

Related tracking: issue #679 (open), issue #775 (open), PR #735 (closed), PR #840 (open).

Scope: saved GroveDB worktree with revision context 2fa0f133877420a0d9c91ba7bc51b1775ab8c783. This report does not establish that current develop or any deployed application is affected. Focused runtime validation remains outstanding.

Audit source and canonical finding identifiers

Source status: snapshot-backed (git_worktree); plain source locations are used because this is not a sealed commit-only scan.

Audited revision context: 2fa0f133877420a0d9c91ba7bc51b1775ab8c783.

The findings were manually reconciled from a preserved scan bundle. The native scan ended before final completion; these are provisional source-review findings, not a completed native scan certification.

Canonical finding ID: csf_251be3d979afe66445c6b156

Primary fingerprint: codex-security/v1:sha256:fcdfc76cf0cef566df1d0d819a99c7dde9a730461d47b77631f1453a57c1f8f2

Canonical finding ID: csf_6ae52e0d802fe222eebd4233

Primary fingerprint: codex-security/v1:sha256:bf039990d7a878a93afb89df71caeb26e1a476e95752f2497f941cf74c1c7f8f

Source locations:

• Location (root_control): grovedb/src/replication/state_sync_session.rs:291
• Location (entrypoint): grovedb/src/replication/state_sync_session.rs:591
• Location (expected_control): grovedb/src/replication/state_sync_session.rs:257
• Location (sink): storage/src/rocksdb_storage/storage.rs:634
• Location (root_control): grovedb/src/replication/state_sync_session.rs:290-294
• Location (propagation): grovedb/src/replication/state_sync_session.rs:591-613
• Location (outcome): grovedb/src/replication/state_sync_session.rs:257-276
• Location (sink): storage/src/rocksdb_storage/storage.rs:634-642
• Location (root_control): grovedb/src/replication/state_sync_session.rs:291-294
• Location: grovedb/src/replication/state_sync_session.rs:591-598
• Location: grovedb/src/replication/state_sync_session.rs:235-276
• Location (entrypoint): grovedb/src/replication/state_sync_session.rs:591-598
• Location (root_control): grovedb/src/replication/state_sync_session.rs:290-295
• Location (expected_control): grovedb/src/replication/state_sync_session.rs:257-269
• Location (root_control): grovedb/src/replication/state_sync_session.rs:291-293
• Location (entrypoint): grovedb/src/replication/state_sync_session.rs:590-598
• Location (expected_control): grovedb/src/replication/state_sync_session.rs:257-276

[QuantumExplorer]

Downgrading high → low after adversarial verification. The non-atomicity is real but already known and self-documented: the TODO at state_sync_session.rs:252-255 describing exactly this was added together with the final root-hash check in #558 (the previous audit's H3 fix), so this is a re-report of a triaged residual. There is no attacker leverage: every intermediate-committed subtree is chunk-verified against the expected-hash chain rooted at the consensus app_hash, so partially committed state can only ever be genuine snapshot data — worst case is a leftover partial-but-genuine snapshot after an aborted sync, a node-local operational hazard requiring a wipe. State sync also has no production callers in the 4.0 release line, and the prospective drive-abci integration wipes GroveDB before every session. The proper fix (stage batches until final verification) should land before state sync ships.

[QuantumExplorer]

This is Claude, closing on behalf of the maintainer.

Duplicate of #775, and resolved by the same change in #840 (6ec8fee): subtree batches are no longer flushed before the final root verification. In the default atomic mode nothing reaches the database until commit_session passes the app-hash check; the suggested test (small batch size, corrupt a later chunk, assert the destination is untouched) exists as failed_chunk_after_batched_sync_rolls_back_all_restored_subtrees.