[deadp]

This branches from #13. Only the last commit (exfat: bound contiguous run expansion at cluster heap end) is new. Once #13 merges, this diff shrinks to that commit alone.

Problem

ExfatFS.chain() with contiguous=True expanded a NoFatChain run into one list element per cluster, where the cluster count came from the untrusted stream-entry length, not the boot sector: a corrupt 2^50 length meant a 2^40-element list(range(start, start + n)) — hang or MemoryError on any read of that file (engine/fs/exfat.py, contiguous branch). The non-contiguous branch was already bounded by its 2 <= c < cluster_count + 2 walk; only the contiguous one was not.

Found by the fuzz corpus: fuzz-findings/exfat-memory-4c12571f.bin replayed the hang. Flip-test substrate from #13 (test_contiguous_run_bounded_by_cluster_heap) pinned the expected bound.

Fix

• Clamp the contiguous run at the cluster heap end: limit = cluster_count + 2 - start, so a run starting at start ends at byte cluster_offset(start + n) <= cluster_offset(cluster_count + 2). This matches the assertion the Add parser tests, fuzzing, request-gate tests and CodeQL #13 flip test already makes.
• Report a finding when a run is truncated: "Contiguous run from cluster %d truncated at cluster heap end.", appended only if not already present (server-side FS objects are cached per evidence and runs() is called per stat/read, so a plain append would duplicate the entry in the UI).
• Expose findings through ExfatFS.info() ("findings": self.findings), mirroring HfsPlusFS — findings reach the UI only via fs.info() in server.py (/api/dir). NtfsFS collects findings but does not surface them through info().
• Representation is unchanged: still a list(range(...)) of clusters, so all callers (_read_dir_bytes, runs(), _load_bitmap, allocated_extents) behave as before; the mount-time callers (_load_bitmap, allocated_extents) use the non-contiguous branch and can never append this finding.
• Removed the @unittest.expectedFailure from test_contiguous_run_bounded_by_cluster_heap — it now passes as a normal test.

No changelog entry here by design; CHANGELOG.md lives on the changelog branch (#16) and the entry consolidates there.

Verification

• Full suite: 289 tests, OK (16 expected failures, down from 17 — the flipped test now passes normally).
• tests/fuzz.py --replay fuzz-findings/exfat-memory-4c12571f.bin: exits clean, no hang/MemoryError.
• tests/smoke.py: all checks passed.
• Patched-image check (same mutation as the flip test): fs.info()["findings"] == ["Contiguous run from cluster 10 truncated at cluster heap end."] (exactly one, stable across repeated runs() calls), and every run satisfies offset + length <= cluster_offset(cluster_count + 2).

Fixes part of #15; test substrate from #13.

[switch-nz]

Merged — reviewed and verified against current main (with #14 and #20): 297 tests OK, expected failures 17 → 16, smoke test passes. The dedupe on the finding and surfacing it through info() are both good calls.

One gap to follow up, not a blocker: the clamp is cluster_count + 2 - start, and cluster_count is the raw u32 from boot sector bytes 92–96, never checked against the volume's actual size. So the fix holds for the saved fuzz input but not for the bug class — corrupt that field as well and the bound goes with it.

Measured by swapping exfat.list for a stub that records len(range(...)) without allocating, on the test_contiguous_run_bounded_by_cluster_heap image with a 2^50 stream length:

cluster_count in boot sector	List elements requested
genuine (64)	56
2^28	268,435,448
0xFFFFFFFF	4,294,967,287

All three mount. The last is the same memory exhaustion as before, one 4-byte mutation away, so the fuzzer will likely rediscover it.

Two ways to close it, either sufficient:

1. Bound cluster_count at mount — clamp to what the volume can hold, (source.size - data_offset) // cluster_size, with a finding when the boot sector claims more. This also protects the FAT-walk branch and every other user of cluster_count.
2. Stop materialising contiguous runs — represent them as (start, count) as Fuzzer findings: exFAT run-list memory exhaustion, jbd2 AttributeError, NTFS record-count hang #15 suggested, so no length allocates anything.

(1) is the smaller change; (2) removes the allocation class entirely. I've noted on #15 that item 1 is partly fixed rather than done.