### Summary On 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation. ### 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`: ```rust 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 `AlignedGrid`s 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()`. ### Impact On 32-bit platforms this can cause out-of-bounds writes with attacker-controlled data when decoding a crafted JPEG XL image. This could allow arbitrary code execution.
### Summary On 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation. ### 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`: ```rust 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 `AlignedGrid`s 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()`. ### Impact On 32-bit platforms this can cause out-of-bounds writes with attacker-controlled data when decoding a crafted JPEG XL image. This could allow arbitrary code execution.
### Summary On 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation. ### 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`: ```rust 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 `AlignedGrid`s 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()`. ### Impact On 32-bit platforms this can cause out-of-bounds writes with attacker-controlled data when decoding a crafted JPEG XL image. This could allow arbitrary code execution.
### Summary On 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation. ### 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`: ```rust 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 `AlignedGrid`s 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()`. ### Impact On 32-bit platforms this can cause out-of-bounds writes with attacker-controlled data when decoding a crafted JPEG XL image. This could allow arbitrary code execution.
Update jxl-grid to 0.6.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanjxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow affects jxl-grid (rust). Severity is high. ### Summary On 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation. ### 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`: ```rust 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 `AlignedGrid`s 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()`. ### Impact On 32-bit platforms this can cause out-of-bounds writes with attacker-controlled data when decoding a crafted JPEG XL image. This could allow arbitrary code execution.
AI coding agents often install or upgrade packages automatically in rust. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| jxl-gridrust | <=0.6.1 | 0.6.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate jxl-grid to 0.6.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanjxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow affects jxl-grid (rust). Severity is high. ### Summary On 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation. ### 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`: ```rust 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 `AlignedGrid`s 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()`. ### Impact On 32-bit platforms this can cause out-of-bounds writes with attacker-controlled data when decoding a crafted JPEG XL image. This could allow arbitrary code execution.
AI coding agents often install or upgrade packages automatically in rust. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| jxl-gridrust | <=0.6.1 | 0.6.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard