RUSTSEC-2026-0151: Out-of-bounds writes due to integer overflow in jxl-grid on 32-bit platforms

What to do

1. See which version you have: cargo tree -i jxl-grid (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p jxl-grid. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example jxl-grid = "0.6.2") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

On 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation. This could allow arbitrary code execution.

Details & PoC

The test listed below fail under miri with command cargo +nightly miri test --release -p jxl-grid

Or you can use Address Sanitizer, which ignores Rust-specific UB like aliasing but still flags out-of-bounds accesses:

RUSTFLAGS=-Zsanitizer=address cargo +nightly test -Zbuild-std -p jxl-grid --release --target x86_64-unknown-linux-gnu

The following tests should be appended to crates/jxl-grid/src/test/subgrids.rs:

mod miri_ub {
    use super::*;

    // `AlignedGrid::with_alloc_tracker` computes `width * height` unchecked. In release, overflow
    // can create a tiny backing buffer for huge logical dimensions.
    #[test]
    fn aligned_grid_dimension_product_overflows() {
        let width = usize::MAX / 2 + 1;
        let mut grid = AlignedGrid::<u8>::with_alloc_tracker(width, 2, None).unwrap();
        let mut subgrid = grid.as_subgrid_mut();
        *subgrid.get_mut(0, 1) = 1;
        std::hint::black_box(grid);
    }
}

This issue can be reachable through decoding a crafted image in two ways:

1. **Huge actual frame** A frame such as 65536 x 65536 passes the current frame area limit (2^32 <= 2^40) but overflows usize element count on 32-bit. Rendering then allocates too-small AlignedGrids in modular/VarDCT/filter paths and later writes through mutable subgrids.

2. **Huge canvas plus tiny cropped frame** This is the more practical “small payload, huge logical output” case. A bitstream-controlled frame crop can be tiny, but if the canvas/default requested region is huge, composition can allocate an output grid sized to the canvas/ROI at crates/jxl-render/src/blend.rs. That is bitstream frame cropping, not API crop. With a 32-bit target and a full requested image region whose area overflows, this can happen through ordinary render_frame().

References

• Package: crates.io/crates/jxl-grid
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0151.html
• Web: github.com/tirr-c/jxl-oxide/commit/3986dadd3926a95656a642e74a0702d52f5c92e2

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.