rustsec-2026-0151
Vulnerability from osv_rustsec
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:
-
Huge actual frame A frame such as
65536 x 65536passes the current frame area limit (2^32 <= 2^40) but overflowsusizeelement count on 32-bit. Rendering then allocates too-smallAlignedGrids 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().
| URL | Type | |
|---|---|---|
{
"affected": [
{
"database_specific": {
"categories": [
"memory-corruption"
],
"cvss": null,
"informational": null
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "jxl-grid",
"purl": "pkg:cargo/jxl-grid"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-0"
},
{
"fixed": "0.6.2"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [
"GHSA-5pmv-rx8r-wmv5"
],
"database_specific": {
"license": "CC0-1.0"
},
"details": "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.\n\n### Details \u0026 PoC\n\nThe test listed below fail under miri with command `cargo +nightly miri test --release -p jxl-grid`\n\nOr you can use Address Sanitizer, which ignores Rust-specific UB like aliasing but still flags out-of-bounds accesses:\n\n`RUSTFLAGS=-Zsanitizer=address cargo +nightly test -Zbuild-std -p jxl-grid --release --target x86_64-unknown-linux-gnu`\n\nThe following tests should be appended to `crates/jxl-grid/src/test/subgrids.rs`:\n\n```rust\nmod miri_ub {\n use super::*;\n\n // `AlignedGrid::with_alloc_tracker` computes `width * height` unchecked. In release, overflow\n // can create a tiny backing buffer for huge logical dimensions.\n #[test]\n fn aligned_grid_dimension_product_overflows() {\n let width = usize::MAX / 2 + 1;\n let mut grid = AlignedGrid::\u003cu8\u003e::with_alloc_tracker(width, 2, None).unwrap();\n let mut subgrid = grid.as_subgrid_mut();\n *subgrid.get_mut(0, 1) = 1;\n std::hint::black_box(grid);\n }\n}\n```\n\nThis issue can be reachable through decoding a crafted image in two ways:\n\n1. **Huge actual frame**\n A frame such as `65536 x 65536` passes the current frame area limit (`2^32 \u003c= 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.\n\n2. **Huge canvas plus tiny cropped frame**\n This is the more practical \u201csmall payload, huge logical output\u201d 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()`.",
"id": "RUSTSEC-2026-0151",
"modified": "2026-05-29T18:55:26Z",
"published": "2026-05-29T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/jxl-grid"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0151.html"
},
{
"type": "ADVISORY",
"url": "https://github.com/tirr-c/jxl-oxide/security/advisories/GHSA-5pmv-rx8r-wmv5"
}
],
"related": [],
"severity": [],
"summary": "Out-of-bounds writes due to integer overflow in jxl-grid on 32-bit platforms"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.