Conversation
The module documents "Returns `None` on truncated/invalid data — never panics", but four sites added a length read from the input to a header width in plain `usize`: the STR32, BIN32 and EXT32 arms of `skip_value`, and `start + len` in the string read path. `5 + 0xffff_ffff` fits in a 64-bit `usize` and the buffer check rejects it; on a 32-bit target the addition overflows first and the process aborts. `checked_advance_len` performs both additions checked, and `checked_advance`, `read_u16_be`, `read_u32_be`, `read_u64_be`, `read_str`, `read_str_advance`, `read_bin_advance`, the field index and the field lookup all route through it. The existing adversarial-length test already covers all four sites; it is red->green on a 32-bit target and green on both before and after on a 64-bit one, which is why this went unnoticed: wasm32-wasip1, fix reverted: FAILED, "attempt to add with overflow" wasm32-wasip1, fix applied: PASS x86_64, either: PASS
Contributor
Author
|
Closing: the linked issue is closed. The finding itself is hostile-input hardening on 32-bit usize, not wasm work. If the maintainer wants it, it returns as a fresh PR with that framing. |
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
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.
query: check the additions a hostile msgpack length drives
Why
The reader module documents "Returns
Noneon truncated/invalid data — neverpanics", and four sites broke that contract by adding a length read from the
input to a header width in plain
usize:STR32,BIN32andEXT32arms ofskip_valuestart + lenin the string read path5 + 0xffff_fffffits in a 64-bitusize, so the buffer check rejects it andthe value is discarded as intended. On a 32-bit target the addition overflows
first and the process aborts with
attempt to add with overflow— a hostileframe turning a decode failure into a crash.
What changed
checked_advance_lenperforms both additions checked, andchecked_advance,read_u16_be,read_u32_be,read_u64_be,read_str,read_str_advance,read_bin_advance, the field index and the field lookup all route through it.Every
header/lenpair was checked against its tag width; none changed value.Strictly narrower input is rejected. No input that was accepted before is
rejected now.
Steps to test
cargo nextest run -p nodedb-query -E 'test(fuzz_adversarial_length_fields)'The existing adversarial-length test already covers all four sites. It is the
red arm on a 32-bit target and green on a 64-bit one either side of the change,
which is why the defect survived:
wasm32-wasip1attempt to add with overflowx86_64Run it under a 32-bit target to see the failure: