- Reported
-
- Issued
-
- Package
-
jxl-grid
(crates.io)
- Type
-
Vulnerability
- Categories
-
- Aliases
-
- References
-
- Patched
-
Description
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;
id = "RUSTSEC-2026-0151"
id = "RUSTSEC-2026-0151"
*subgrid.get_mut(0, 1) = 1;
std::hint::black_box(grid);
}
}
This issue can be reachable through decoding a crafted image in two ways:
-
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.
-
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().
Advisory available under CC0-1.0
license.