Skip to content

o8v-fs: no file-size guard on read_to_end / safe_read — latent OOM #5

@xsoheilalizadeh

Description

@xsoheilalizadeh

Summary

o8v-fs reads file contents into Vec<u8> with no size cap. The most visible site is safe_append_with_separator (which holds an exclusive flock during the read), but safe_read and other read_to_end call sites in o8v-fs are also unbounded.

Why this matters

Running 8v write --append on a large log file or binary will allocate and hold the entire file in memory under the lock. A 1 GB file → 1 GB heap → potential OOM. Same shape applies to safe_read for any large file.

What "fixed" looks like

  • A crate-level constant MAX_FILE_BYTES (or similar), e.g. 64 MB, configurable
  • Functions that currently do read_to_end either (a) return an error when the file exceeds the limit, or (b) stream where it's feasible (append's separator detection only needs the last few bytes once we know the file is well-formed; mixed-ending validation can be a streaming scan)

Out of scope

  • Changing the public API of safe_read to return a streaming iterator. That's a bigger redesign.
  • Per-command flags. The limit should be a static crate-level guarantee.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/fso8v-fs (safe filesystem access)enhancementNew feature or improvement

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions