Fix panic on out-of-bounds SSTable sparse index offsets#113
Merged
Conversation
A corrupt or stale .meta file (or a truncated .tbl after a partial write) could contain index offsets past the end of the data file. SsTable::get sliced the mmap/raw buffer with that offset directly, panicking and crashing the server on the next read of the affected key. Treat an out-of-range offset as a stale index and fall back to scanning the table from the start, so lookups stay correct without panicking. https://claude.ai/code/session_01CJXWjB9ERGgV6B9mRqrdM9
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
SsTable::getslices the mmap/raw buffer directly with an offset taken from the sparse index (&mmap[offset as usize..], sstable.rs:190/200). The index is loaded from the separately stored.metaprotobuf with no validation, so a corrupt or stale meta file — or a.tbltruncated by a partial write — can carry an offset past EOF. The next read of an affected key panics and crashes the server.Fix
Treat an out-of-range offset as a stale index: fall back to scanning the table from the start (
mmap.get(offset..).unwrap_or(&mmap[..])). Lookups stay correct (no false negatives from a bad index) and never panic. Both the local mmap path and the remote-storage fallback path are covered.Tests
out_of_bounds_index_offset_does_not_panic: corrupts the in-memory index withu64::MAXoffsets and verifies lookups still succeed via the fallback scan.out_of_bounds_index_offset_remote_storage_does_not_panic: same, through a storage wrapper that hideslocal_path()to exercise the remote read path.Found by codebase audit (high severity: remote-crash DoS via corrupt metadata).
https://claude.ai/code/session_01CJXWjB9ERGgV6B9mRqrdM9
Generated by Claude Code