[audit][medium] Storage removal addition drops default-section removals

[QuantumExplorer]

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

Summary

Combining basic and sectioned storage removals removes/updates the default identifier entry but does not reinsert it.

Impact / failure scenario

Removal bytes from the default identifier can be lost, undercounting storage removals and any costs derived from them.

References

• costs/src/storage_cost/removal.rs:83
• costs/src/storage_cost/removal.rs:102
• costs/src/storage_cost/removal.rs:148

Suggested fix

Reinsert the updated default epoch map before returning or assigning the combined SectionedStorageRemoval.

Suggested tests

Assert Basic + Sectioned(default), Sectioned(default) + Basic, and AddAssign all preserve both removal amounts.

---

September 2026 audit addendum — C008

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

The audited mixed Basic/Sectioned removal branches detach and update the default-owner epoch map without reinserting it. This loses existing epoch attribution and incoming basic bytes. The audit also traces KeyValueStorageCost::combined_removed_bytes and final storage accumulation. Sectioned += Basic is already the effective sibling control and must not be regressed. This is the existing #683 defect, not unauthorized credit creation.

Expected contract and correction: Apply the version-selected correction proposed in #726 while preserving legacy V1-V3 results as required. Cover every mixed branch and aggregation order. The PR body reports that callers aggregating outside GroveDB must select the corrected behavior separately; that downstream integration is not independently verified here.

Validation to complete

• Pin legacy outputs and corrected mixed-order/default-epoch totals.
• Keep the always-correct Sectioned += Basic branch unchanged on legacy versions.
• Verify GroveDB entry-point guards and document external aggregation requirements.

Limits and existing work

• PR fix(costs): version default-section storage removal accounting #726 claims downstream refund relevance; the audit did not execute or independently verify a monetary integration.

Related tracking: issue #683 (open), PR #726 (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_d0684b045cb881581559eaaa

Primary fingerprint: codex-security/v1:sha256:5cac73b5027bfe0390f2ba6beb3ca2b251729abd9efff2e3f012f1a997fe145d

Source locations:

• Location (root_control): costs/src/storage_cost/removal.rs:65-119
• Location (implementation): costs/src/storage_cost/removal.rs:140-183
• Location (implementation): grovedb-epoch-based-storage-flags/src/lib.rs:745-767
• Location (implementation): storage/src/rocksdb_storage/storage.rs:389-404
• Location (root_control): costs/src/storage_cost/removal.rs:76-90
• Location (alternate_route): costs/src/storage_cost/removal.rs:95-109
• Location (alternate_route): costs/src/storage_cost/removal.rs:146-160
• Location (entrypoint): costs/src/storage_cost/key_value_cost.rs:113-116
• Location (sink): storage/src/rocksdb_storage/storage.rs:398-401

[QuantumExplorer]

Re-rating high → medium after adversarial verification. Confirmed real and the most significant finding of this audit batch: three of the four Add/AddAssign arms combining BasicStorageRemoval with SectionedStorageRemoval drop the entire default-identifier section plus the basic bytes being folded in, and the path is reachable from Drive execution (default-identifier StorageFlags sections and basic-removal fallbacks accumulate into the same pending cost). Not high, because the error is deterministic across all nodes — identical undercounted refunds everywhere — so there is no divergence, halt, or credit inflation; the impact is users being under-refunded. The fix (#726, version-gated to GROVE_V3 with legacy semantics preserved for replay) should land before the 4.0 protocol version freezes, since fixing it afterward requires a GROVE_V4 bump and bakes the wrong refunds into mainnet history for the 4.0 era.