Skip to content

[audit][S10] Chunk identifier recovery exceeds the valid tree-depth work bound #883

Description

@QuantumExplorer

Audit group: S10. Classification: security. Provisional severity: medium.

Static review of audited snapshot 2fa0f133 identifies request-length-driven recursion in the chunk producer's traversal recovery. If untrusted state-sync requests reach this API without an upstream size bound, recovery work is not limited by the valid depth of the local tree. This is a conditional medium availability finding, not a measured failure threshold or a claim about current develop deployment.

The expected contract is that a chunk identifier addresses a valid traversal in the source tree and that recovery from a non-boundary position remains bounded by that tree. Identifier conversion checks permitted byte values but does not impose a length bound. The producer then invokes a recovery helper that responds to a failed traversal conversion by shortening the traversal and recursively trying again. The underlying converter has a valid-depth check; the recovery layer does not use that rejection to terminate over-depth requests.

Local empty-tree checks, nonbinary-input rejection and eventual index/link validation remain effective controls for their own conditions. They do not bound this intervening recovery algorithm. Exact stack behavior depends on compiler optimization and host configuration, and no stack exhaustion, process outage or operational threshold was measured. An integration that bounds identifiers before the producer may contain the exposure.

Reject traversal lengths beyond the local tree's valid bound before recovery and replace recursive backtracking with a bounded calculation. Document producer request limits so direct callers receive the same protection as callers using packed transport. Preserve recovery for ordinary valid identifiers that do not fall exactly on a chunk boundary.

Closed issue #696 concerns allocation and copying during packed-message unpacking; this finding is the later producer recovery algorithm and requires its own bound. Issue #704 concerns byte canonicalization, and PR #481 caps proof execution operations. These are related resource controls, not the same mechanism. This provisional review used static source evidence only, with no input reproduction, network endpoint, compiler experiment or runtime test.

Validation to complete

  • Check valid traversal recovery is bounded by local tree geometry.
  • Require over-depth identifiers to fail before recursive recovery work.
  • Verify public producer paths enforce the same length rule independent of packed transport.

Limits and existing work

Related tracking: issue #696 (closed), issue #704 (open), PR #481 (merged), 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_044275fd001d329874329376

Primary fingerprint: codex-security/v1:sha256:707601f55bdbf9cd997d8020b709ae4bc67259df58c965e7468448a2259babf1

Source locations:

  • Location (entrypoint): grovedb/src/replication.rs:175-191
  • Location (propagation): merk/src/merk/chunks.rs:119-137
  • Location (sink): merk/src/proofs/chunk/util.rs:276-306
  • Location (root_control): merk/src/proofs/chunk/util.rs:327-341

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:state-syncS groups: state restoration, synchronization and append-client transactions.audit:2026-09Reconciled September 2026 GroveDB audit; audited worktree at 2fa0f133.audit:needs-validationSaved source evidence reviewed; focused runtime and deployment validation outstanding.bugSomething isn't workingseverity:medium-provisionalMedium impact in the audited scenario; provisional static assessment.type:securityAudit reports a security property failure; deployment impact needs validation.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions