[audit][medium] Non-empty tree delete can reopen parent with child tree type

[QuantumExplorer]

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

Summary

Direct delete of a non-empty child tree can reopen the parent path using the child tree’s tree_type.

Impact / failure scenario

Deleting under CountTree/sum/count-sum parents with allow_deleting_non_empty_trees=true can propagate aggregate/root metadata incorrectly.

References

• grovedb/src/operations/delete/mod.rs:740
• grovedb/src/operations/delete/mod.rs:750
• grovedb/src/operations/delete/mod.rs:847
• grovedb/src/operations/delete/mod.rs:880

Suggested fix

Reopen with the parent’s saved tree type or reuse the already-open parent subtree handle.

Suggested tests

Delete a non-empty child under an aggregate parent, then verify aggregate count/sum and verify_grovedb.

---

September 2026 audit addendum — M014

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

The reviewed snapshot's populated-child deletion reopens the parent as a layered Merk using the deleted child's tree type. Besides the known link-hash/type problem, this can lose base-root pointer maintenance. Empty-child deletion retains the original parent and avoids this route. This is an addendum to the existing #686 root cause. GitHub metadata marks #732 merged; its description reuses the parent under V4 and deliberately preserves V1-V3 behavior. The audit does not establish that the described V4 fix is incomplete, nor that current develop remains affected.

Expected behavior: Deleting a populated child must retain the parent's actual Merk mode and tree type, including base-root pointer maintenance.

Fix direction: Reuse the already opened parent or reopen it through the canonical parent-path helper preserving both MerkType and TreeType. Cover surviving siblings at the base root and nested parent/child type differences. Version persistent root changes where replay compatibility requires it.

Validation to complete

• Suggested: verify the described V4 parent-reuse fix on its actual target before proposing further remediation.
• Cover base-root deletion with surviving siblings and nested differing parent/child types; preserve legacy replay expectations.

Limits and existing work

• PR fix(delete): preserve parent type for non-empty subtree deletes #732 is marked merged and explicitly keeps legacy V1-V3 behavior; no new current-develop or V4 regression claim is made.

Related tracking: issue #686 (closed), PR #732 (merged).

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_c5080c5878555bc3a3cec243

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

Source locations:

• Location (root_control): grovedb/src/operations/delete/mod.rs:973-987
• Location (propagation): grovedb/src/operations/delete/mod.rs:1011-1019
• Location (outcome): merk/src/merk/mod.rs:369-381
• Location (outcome): merk/src/tree/mod.rs:704-724
• Location (entrypoint): grovedb/src/operations/delete/mod.rs:755-795
• Location (root_control): grovedb/src/operations/delete/mod.rs:950-1040
• Location (root_control): merk/src/merk/open.rs:70-95
• Location (root_control): merk/src/merk/mod.rs:235-283
• Location (root_control): merk/src/merk/mod.rs:399-450
• Location (root_control): merk/src/merk/mod.rs:582-625
• Location (root_control): grovedb/src/lib.rs:675-744
• Location (root_control): merk/src/tree/mod.rs:698-750

[QuantumExplorer]

Re-rating high → medium after adversarial verification. The bug is real — deleting a non-empty subtree reopens the parent Merk with the child's tree type, and a verify_grovedb hash mismatch was empirically reproduced with a ProvableCountTree parent on the legacy path (real state corruption, not just cost skew). Not high, because the path is unreachable from Drive today: every DeleteOptions construction site sets allow_deleting_non_empty_trees: false, the batch path returns NotSupported, and the default is false — so it is a hazard for direct GroveDB API consumers and future Drive features only. Fix is #732 (legacy path byte-exact, corrected behavior gated to GROVE_V3); one ask there before/right after merge: add a Provable*-parent regression test that actually fails on the legacy path, since the PR's current tests pass pre-fix.