safe-fs security review: assess caller-controlled allocations in direct read APIs

[kamilio]

Finding and validation status

Daybreak Blue source review found direct real-filesystem read APIs admit caller-controlled safe-integer allocation sizes without an operational upper bound. Reachability from untrusted safe-bash input has not been demonstrated; treat this as a hardening candidate pending validation.

Current-code evidence

• openReadFile read validates position/maxBytes and allocates Uint8Array(maxBytes), catching allocation errors as EFBIG.
• readStream validates chunkSize and allocates Uint8Array(min(chunkSize, end-position)).

A direct SDK consumer or custom command forwarding untrusted size values could request excessive allocations. Existing maintained shell callers generally supply bounded values. Direct trusted JavaScript callers already have allocation capability, so a concrete untrusted caller path is necessary to establish a security vulnerability.

Impact and validation limits

Potential memory pressure or process failure when an application exposes these sizes to an untrusted caller. No destructive allocation/OOM reproduction was run. Reviewed source at d126d35; no confirmed default-shell DoS is claimed.

Acceptance criteria

• Trace supported untrusted caller paths and current size bounds.
• Reproduce excess allocation admission safely with mocked allocation/native I/O rather than exhausting memory.
• If a reachable issue is confirmed, add appropriate budget admission and focused regression coverage; otherwise document the trusted-caller boundary and close as non-vulnerability.

[kamilio]

Assessed and documented on remote main in 4af337d. Fourteen in-memory tests safely intercept oversized Uint8Array requests before allocation and trace retained reads, streams, bridge admission and actual maintained head/cmp/redirection callers. Direct trusted SDK callers can request excessive sizes, but no maintained guest path to these raw size arguments was established; tested shell requests remain bounded. See docs/plans/726-real-fs-read-budget-review.md for the caller trace and limits. Closing as a non-vulnerability under the documented trusted-caller contract, not as a new allocation cap or universal DoS-resistance claim. Custom embeddings must admit per-read, cumulative, concurrency and lifetime budgets before forwarding untrusted sizes; reopen if a supported unchecked forwarding path is identified.