[audit][P04] Descending bulk and commitment proof reads return the opposite end of a range

[QuantumExplorer]

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

Bulk range extraction sorts positions ascending, and the commitment-tree verifier uses the same helper. The integrated result loop applies a limit without first honoring descending query direction, potentially returning entries from the opposite end of the requested range. Root and value binding remain effective.

Apply the trusted direction before consuming the shared limit and align generator, direct read, and verifier ordering.

Closed #688 and PR #729 address short completed chunk contents, which is a different completeness invariant. PR #786 adds ascending canonical page APIs; that does not establish correctness of general descending subqueries. MMR/dense proof-vector ordering remains a separate audit group.

Source-based assessment only; this audit did not reproduce the reported behavior at runtime.

Validation to complete

• Compare direct reads, generated proofs, and verified limited results in both directions for bulk and commitment trees.

Related tracking: issue #688 (closed), PR #415 (merged), PR #786 (merged), PR #729 (closed).

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_0e6caf6d3b91a6a1e0b94d2c

Primary fingerprint: codex-security/v1:sha256:63107166e8184971a9527455c063bcd57b09f1dc746d18528851cab66d471a38

Canonical finding ID: csf_09a28f897c0678dbc0c5c0a0

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

Source locations:

• Location (root_control): grovedb-bulk-append-tree/src/proof/mod.rs:671-672
• Location (outcome): grovedb/src/operations/proof/verify.rs:2492-2499
• Location (root_control): grovedb/src/operations/proof/verify.rs:2322-2382
• Location (propagation): grovedb-merkle-mountain-range/src/proof.rs:587-607
• Location (counterevidence): grovedb-merkle-mountain-range/src/proof.rs:268-287
• Location (propagation): grovedb-bulk-append-tree/src/proof/mod.rs:650-681
• Location (sink): grovedb/src/operations/proof/verify.rs:2459-2497
• Location (propagation): grovedb/src/operations/proof/verify.rs:2532-2563

[QuantumExplorer]

This is Claude. Closed by the merge of #866: the bulk crate's verify_against_query now orders matched rows by the query direction before applying the limit, and the outstanding runtime validation (direct range reads vs verified proof windows, both directions, global and per-instance caps, for bulk and commitment trees) is checked in as grovedb/src/tests/append_layer_direction_tests.rs. The GroveDB verifier itself was already direction-correct since #847, which the audited snapshot predated.