Add regression coverage for the list pre-allocation DoS guard#27
Open
ilitteri wants to merge 1 commit into
Open
Add regression coverage for the list pre-allocation DoS guard#27ilitteri wants to merge 1 commit into
ilitteri wants to merge 1 commit into
Conversation
The fix in #24 added panic-sentinel tests, but those only exercise the capped SszList path. The more severe, uncapped paths — Vec<T> and ProgressiveList — have no max-length backstop and rely solely on the out-of-bounds first-offset check running before Vec::with_capacity. Nothing tested that, so a future refactor could drop the guard and leave every test passing. - ssz: assert Vec<Vec<u8>> rejects an oversized first offset before allocating - ssz-types: same assertion for ProgressiveList<Vec<u8>> - offset_adversarial fuzz: add a variable-size-element collection (Vec<Vec<u8>>), the offset-table allocation path the existing fixed-element targets never hit - decode: document why the early first-offset bound check must not be removed Closes #25.
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
1 participant
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.
Follow-up to #24 / #25.
The fix in #24 prevents the pre-allocation OOM, but its tests (panic sentinels) only cover the capped
SszListpath. The most severe variant is the uncapped one:Vec<T>andProgressiveListdecode with no max-length backstop and depend entirely on the out-of-bounds first-offset check running beforeVec::with_capacity. Nothing exercised that, so a future refactor could weaken the guard with every test still green.Changes
crates/ssztest —Vec::<Vec<u8>>::from_ssz_byteswith an oversized first offset (0xFFFFFFFCin an 8-byte buffer) must returnOffsetOutOfBoundsbefore allocating.crates/ssz-typestest — same assertion forProgressiveList<Vec<u8>>(adds a test module; the file had none).offset_adversarialfuzz target — add a variable-size-element collection (Vec<Vec<u8>>, plus a derived struct field). The existing target only used fixed-sizeu8elements, so it never reached the offset-table allocation — the blind spot that hid this class.decode.rscomment — document why the earlyfirst_offset > bytes.len()check must stay (it looks redundant with the per-offset loop check, but that one runs after allocating).No production code behavior change — tests, fuzz coverage, and a comment only.
Verification
cargo test -p libssz -p libssz-types— both new tests pass; full suite green.cargo fmt --checkandcargo clippyclean.cargo +nightly fuzz run offset_adversarialbuilds and runs with no crashes.