jxl-grid

Version	Released
`0.6.2` unknown	May 29, 2026
`0.6.1` unknown yanked 1 CVE	Aug 02, 2025
`0.6.0` unknown yanked 1 CVE	Apr 27, 2025
`0.5.3` unknown 1 CVE	Dec 28, 2024
`0.5.2` unknown 1 CVE	Dec 07, 2024
`0.5.1` unknown 1 CVE	Oct 12, 2024
`0.5.0` unknown 1 CVE	Sep 09, 2024
`0.4.2` unknown 1 CVE	Jun 22, 2024
`0.4.1` unknown 1 CVE	Feb 28, 2024
`0.4.0` unknown 1 CVE	Feb 24, 2024
`0.3.0` unknown 1 CVE	Jan 13, 2024
`0.2.0` unknown 1 CVE	Nov 21, 2023
`0.1.1` unknown 1 CVE	May 10, 2023
`0.1.0` unknown 1 CVE	May 07, 2023

0.6.2 unknown

May 29, 2026

0.6.1 unknown yanked

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Aug 02, 2025

0.6.0 unknown yanked

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Apr 27, 2025

0.5.3 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Dec 28, 2024

0.5.2 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Dec 07, 2024

0.5.1 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Oct 12, 2024

0.5.0 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Sep 09, 2024

0.4.2 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Jun 22, 2024

0.4.1 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Feb 28, 2024

0.4.0 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Feb 24, 2024

0.3.0 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Jan 13, 2024

0.2.0 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

Nov 21, 2023

0.1.1 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

May 10, 2023

0.1.0 unknown

1 CVE

CVE-2026-52834 GHSA-5pmv-rx8r-wmv5 RUSTSEC-2026-0151 Jul 02, 2026

jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow

7.3 / 10

High

Local High None None Changed Low Low 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:

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:

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().

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.

Fixed in


          0.6.2

References

Updated Jul 02, 2026 · Source: OSV.dev

May 07, 2023

Activity

Details