RUSTSEC-2026-0220: Uint shift operations: incorrect overflow flags and truncated shift amounts
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 8
- Forks
- 8
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 36
Description
Uint shift operations: incorrect overflow flags and truncated shift amounts
| Details | |
|---|---|
| Package | ruint |
| Version | 1.18.0 |
| URL | https://github.com/alloy-rs/ruint/pull/603 |
| Date | 2026-07-08 |
| Patched versions | >=1.20.0 |
Uint::overflowing_shl/overflowing_shr returned false-negative overflow
flags. overflowing_shl missed bits shifted above BITS but within the top
limb (non-limb-aligned widths such as U160), and limbs wholly discarded by
shifts >= 64; overflowing_shr missed wholly discarded low limbs. Shifted
values were correct; only the flag was wrong.
The wrong flag propagates: checked_shl/checked_shr return Some instead
of None, strict_* fail to panic, and saturating_* return a wrapped
value instead of saturating. The incorrect checked_shl result causes
to_base_be (and string formatting) to loop forever on no-alloc builds for
non-limb-aligned widths — a denial of service if formatting is reachable
from untrusted input.
Separately, wrapping_shl/wrapping_shr on 64/128/256-bit types truncated
the shift amount modulo 2^32, so shifts >= 2^32 returned an incorrectly
wrapped value instead of zero; on 32-bit targets the generic path also
truncated 64-bit shift amounts.
Callers using checked or saturating shift semantics on untrusted shift
amounts may compute incorrect results.
See advisory page for additional details.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no repository files, tests, or entry points. First determine whether this project directly or transitively uses ruint 1.18.0, then review the dependency manifest and lockfile. Done means affected code no longer resolves the vulnerable version, using ruint >=1.20.0, with the project’s available checks passing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- security
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 38/100