What the developer wrote
Authored by Martin Habovstiak
Fix integer overflow in `get_array`
The `get_array` method promised to return `None` in case of
out-of-bounds access but internally tried to add caller-controlled
values which would result in integer overflow. In case overflow happens
the attempted read is certainly out of bounds - goes beyond address
space. Therefore this commit treats it as such and fixes it to return
`None`.
This bug was found by creusot.
What changed, and why it matters
This commit fixes a bug in a Rust helper method called `get_array`, which is meant to safely read a fixed-size chunk from a slice and return nothing if the requested range is out of bounds. The bug was that the code added the caller's offset and length together using normal integer addition, which can overflow on large values. In Rust, integer overflow in release builds is defined to wrap around, so a huge offset plus length could produce a small number, making the out-of-bounds check pass incorrectly. The fix uses checked addition so that any overflow is treated as an out-of-bounds request and returns nothing, as the method's contract promises.
Review all call sites of `get_array` to confirm none relied on the previous overflow behavior, and audit other slice-indexing helpers in the crate for similar unchecked offset/length arithmetic. Consider adding unit tests with `usize::MAX` offsets to prevent regression.
Security signals we found
Integer overflow in bounds calculation
Potential panic due to violated internal length expectation
Caller-controlled arithmetic used for memory access bounds
Fix uses checked_add to enforce documented out-of-bounds contract
Evidence from the diff
The get_array method in internals/src/slice.rs computes the end of a requested sub-slice as offset + ARRAY_LEN. Because both values are caller-controlled and usize addition can silently wrap in release mode, a crafted large offset could cause offset + ARRAY_LEN to wrap to a small value. That small end value would then pass slice::get, potentially returning a short slice that fails the subsequent try_into().expect(...) assertion, causing a panic. The fix replaces the unchecked addition with offset.checked_add(ARRAY_LEN)?, so overflow is converted into None, matching the documented behavior of returning None on out-of-bounds access.
Changed components
internals/src/slice.rsSliceExt::get_arrayInspect captured patch +2 / −1
### internals/src/slice.rs
@@ -96,7 +96,8 @@ impl<T> SliceExt for [T] {
}
fn get_array<const ARRAY_LEN: usize>(&self, offset: usize) -> Option<&[Self::Item; ARRAY_LEN]> {
- self.get(offset..(offset + ARRAY_LEN)).map(|slice| {
+ let end = offset.checked_add(ARRAY_LEN)?;
+ self.get(offset..end).map(|slice| {
slice
.try_into()
.expect("the arguments to `get` evaluate to the same length the return type uses")Why this scored 62/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.