Skip to content

Use wrapping arithmetic in ProbeSeq::move_next to avoid overflow#736

Merged
clarfonthey merged 1 commit into
rust-lang:mainfrom
amitmishra11:fix-probe-seq-overflow
Jul 6, 2026
Merged

Use wrapping arithmetic in ProbeSeq::move_next to avoid overflow#736
clarfonthey merged 1 commit into
rust-lang:mainfrom
amitmishra11:fix-probe-seq-overflow

Conversation

@amitmishra11

Copy link
Copy Markdown
Contributor

Bug

In ProbeSeq::move_next (src/raw.rs), stride and pos are updated with plain +=:

self.stride += Group::WIDTH;
self.pos += self.stride;
self.pos &= bucket_mask;

In a debug build this panics; in a release build it produces undefined behavior (integer overflow). Although the existing debug_assert! verifies that stride <= bucket_mask before the addition, it fires before the increment, so the assert itself does not rule out overflow once Group::WIDTH is added.

This was identified via Kani formal verification and confirmed as a bug by @Amanieu in #735.

Fix

Replace the plain additions with wrapping_add, which is what the subsequent & bucket_mask mask assumes:

self.stride = self.stride.wrapping_add(Group::WIDTH);
self.pos = self.pos.wrapping_add(self.stride) & bucket_mask;

The logic is otherwise identical; wrapping_add only differs from + when overflow would occur, and the final mask ensures pos stays in range regardless.

Verification

cargo check passes cleanly. cargo test cannot run on this machine due to an absent MSVC linker, but the type-level correctness of the change is confirmed by cargo check.

Closes #735

@clarfonthey

Copy link
Copy Markdown
Contributor

It appears that the test failures are due to some unrelated lint changes; I can work on those in a separate PR, or someone else can get to that first. Otherwise, this PR looks fine and can be merged after that is fixed.

@amitmishra11

Copy link
Copy Markdown
Contributor Author

Thanks for the review and for clarifying the CI failures. Happy to wait for those lint changes to land first, or rebase once they're merged if that helps.

@clarfonthey

Copy link
Copy Markdown
Contributor

#738 is the fix; shouldn't need any changes from you once that merges.

@clarfonthey clarfonthey enabled auto-merge July 6, 2026 16:44
@clarfonthey clarfonthey disabled auto-merge July 6, 2026 16:44
@clarfonthey clarfonthey force-pushed the fix-probe-seq-overflow branch from 3871a7c to 841b75b Compare July 6, 2026 16:51
In long probe sequences with a nearly-full table, the stride and pos
fields can overflow using plain += before being masked back. Replacing
the additions with wrapping_add makes the arithmetic well-defined under
all inputs and matches the intent of the subsequent mask (& bucket_mask).

Fixes rust-lang#735

Assisted-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@clarfonthey clarfonthey force-pushed the fix-probe-seq-overflow branch from 841b75b to efa26d7 Compare July 6, 2026 16:52
@clarfonthey

Copy link
Copy Markdown
Contributor

Trying to remember how to push changes to someone else's branch.

@clarfonthey clarfonthey enabled auto-merge July 6, 2026 16:53
@clarfonthey clarfonthey added this pull request to the merge queue Jul 6, 2026
Merged via the queue into rust-lang:main with commit d69025b Jul 6, 2026
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ProbeSeq::move_next() potential arithmetic overflow

2 participants