Vulnerability-Lookup

GHSA-5PMV-RX8R-WMV5

Vulnerability from github – Published: 2026-07-02 20:45 – Updated: 2026-07-02 20:45

Summary

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

Details

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.

Severity ?

7.3 (High)


                  
                    CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.6.1"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "jxl-grid"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52834"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-122",
      "CWE-131",
      "CWE-190"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T20:45:59Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nOn 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation.\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()`.\n\n### Impact\n\nOn 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.",
  "id": "GHSA-5pmv-rx8r-wmv5",
  "modified": "2026-07-02T20:45:59Z",
  "published": "2026-07-02T20:45:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tirr-c/jxl-oxide/security/advisories/GHSA-5pmv-rx8r-wmv5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tirr-c/jxl-oxide"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0151.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "jxl-grid on 32-bit platforms has an out-of-bounds writes due to integer overflow"
}

ghsa-5pmv-rx8r-wmv5

Vulnerability from osv_rustsec

Published

2026-05-29 12:00

Modified

2026-07-03 06:12

Summary

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

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.

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

JSON

To clipboard

{
  "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": [
    "CVE-2026-52834",
    "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-07-03T06:12:08Z",
  "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

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.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-5PMV-RX8R-WMV5

Summary

Details & PoC

Impact

ghsa-5pmv-rx8r-wmv5

Vulnerability from osv_rustsec

Details & PoC

Tags

Sightings

Nomenclature