GHSA-38c5-483c-4qqp

Summary

An integer overflow in Grid::expand_rows() can corrupt the relationship between the grid’s logical dimensions and its backing storage. After the internal invariant is broken, the safe API get() may invoke get_unchecked() with an invalid index, resulting in Undefined Behavior.

Details

Tested Version: grid = "1.0.0"

expand_rows() computes the new backing length using unchecked arithmetic:

self.data.len() + rows * self.cols

If rows * self.cols or the subsequent addition overflows usize, the result wraps in release builds and self.data may be resized to a length much smaller than logically required.

After that, if the grid is in ColumnMajor order, the function performs in-place rotation using indices derived from:

let total_rows = self.rows + row_added;
let col_idx = i * total_rows;
self.data[col_idx..col_idx + total_rows + i].rotate_right(i);

These computations also rely on the assumption that the backing storage has been resized to the correct length. Once the earlier length computation has wrapped, this assumption no longer holds, so the function may operate on invalid ranges or otherwise enter an inconsistent state.

Finally, the function updates logical metadata with:

self.rows += rows;

As a result, the grid can end up with logical dimensions that no longer match the actual backing storage. Subsequent safe API calls such as get() may then rely on corrupted metadata and reach unsafe internal accesses, resulting in invalid unchecked access and Undefined Behavior.

PoC

#![forbid(unsafe_code)]

use grid::Grid;

fn main() {
    let mut g = Grid::from_vec(vec![1u8, 2u8], 2);

    g.expand_rows(usize::MAX / 2);

    g.get(0, 0); // triggers UB in get_unchecked
}

Impact

• Invalid unchecked access (get_unchecked) reached via safe API
• Confirmed by Miri (release-mode):

error: Undefined Behavior: `assume` called with `false`
   --> ..../grid-1.0.0/src/lib.rs:527:9
    |
527 |         self.data.get_unchecked(index)
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Undefined Behavior occurred here

- Potential crash / denial of service in release-builds (e.g., SIGSEGV, Illegal instruction) - Violates Rust’s safety guarantees despite using only safe code