fix(spammer): reject num_generators that would overflow the partition shift#147
Open
Kewe63 wants to merge 1 commit into
Open
fix(spammer): reject num_generators that would overflow the partition shift#147Kewe63 wants to merge 1 commit into
Kewe63 wants to merge 1 commit into
Conversation
… shift The exponential account partitioner in the spammer computed a left shift of num_generators - 1 without first validating the shift distance, in two places: an entry guard and the boundary-building loop. On a 64-bit target, asking for 65 or more generators makes the shift distance reach the platform word width, and the left shift overflows. In debug builds that panics with "attempt to shift left with overflow"; in release builds the shift distance silently wraps, the existing smallest-bucket guard sees a non-zero bucket and lets the input through, and the boundary loop emits 64 zero-length ranges plus a final correct range. Add an up-front precondition that num_generators must be at most usize::BITS, with a clear error message. This is the natural cap: the boundary loop already computes 1usize << (num_generators - 1), and a left shift by usize::BITS overflows. Beyond this cap the partition concept itself breaks down. Add a regression test covering the original 65-generator case, the usize::BITS+1 boundary, and the usize::MAX extreme.
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.
Summary
PartitionMode::Exponential::partition_exponentialincrates/spammer/src/accounts.rsperformed two unchecked left shifts onnum_generators. On a 64-bit target,num_generators >= 65makes the shift distance reachusize::BITSand the<<operation overflows:attempt to shift left with overflow1usize << 64evaluates to1usize << 0 == 1, the smallest-bucket guard sees a non-zero bucket and lets the input through, and the boundary loop emits 64 zero-length ranges plus a final correct rangeVerified locally on
upstream/main(a85368c) before applying the fix.Root Cause
partition_exponentialalready shifts bynum_generators - 1, so the natural upper bound isusize::BITS— a left shift byusize::BITSoverflows on every platform, and beyond that the partition concept breaks down (1 << 63already gives sub-unit smallest buckets for any realisticnum_accounts).Fix
Reject any
num_generators > usize::BITSup front with a clear error message, before either shift is computed.Changes
File:
crates/spammer/src/accounts.rsnum_generators > usize::BITSwith an explicit error.partition_exponential_rejects_shift_overflowcovering:usize::BITS + 1boundaryusize::MAXextremeHow to Test
Pre-existing
partition_accounts_linearandpartition_accounts_exponentialtests are unchanged.Risk & Impact
Low. Validation is purely additive — valid inputs (
num_generators <= usize::BITS) are unaffected. Inputs that previously caused silent UB in release builds or panics in debug builds now return a clear error.Type: 🐛 Bug fix
Closes: #137