ghsa-x22w-82jp-8rvf
Vulnerability from github
Published
2025-07-31 19:23
Modified
2025-08-01 18:35
Summary
OpenEXR Out-Of-Memory via Unbounded File Header Values
Details

Summary

The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window.

The application trusts the value of dataWindow size provided in the header of the input file, and performs computations based on this value.

This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations.

Details

A concrete example of this issue is present in the function readScanline() in ImfCheckFile.cpp at line 235, that performs a for-loop using the dataWindow min.y and max.y coordinates that can be arbitrarily large.

```cpp in.setFrameBuffer (i);

int step = 1;

// // try reading scanlines. Continue reading scanlines // even if an exception is encountered // for (int y = dw.min.y; y <= dw.max.y; y += step) // <-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX { try { in.readPixels (y); } catch (...) { threw = true;

    //
    // in reduceTime mode, fail immediately - the file is corrupt
    //
    if (reduceTime) { return threw; }
}

} ```

Another example occurs in the EnvmapImage::resize function that in turn calls Array2D<T>::resizeEraseUnsafe passing the dataWindow X and Y coordinates and perform a huge allocation.

On some system, the allocator will simply return std::bad_alloc and crash. On other systems such as macOS, the allocator will happily continue with a "small" pre-allocation and allocate further memory whenever it is accessed. This is the case with the EnvmapImage::clear function that is called right after and fills the image RGB values with zeros, allocating tens of Gigabytes.

PoC

NOTE: please download the oom_crash.exr file via the following link:

https://github.com/ShielderSec/poc/tree/main/CVE-2025-48074

  1. Compile the exrcheck binary in a macOS or GNU/Linux machine with ASAN.
  2. Open the oom_crash.exr file with the following command:

exrcheck oom_crash.exr

  1. Notice that exrenvmap/exrcheck crashes with ASAN stack-trace.

Impact

An attacker could cause a denial of service by stalling the application or exhaust memory by stalling the application in a loop which contains a memory leakage.

Show details on source website


{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "OpenEXR"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.3.2"
            },
            {
              "fixed": "3.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.3.2"
      ]
    }
  ],
  "aliases": [
    "CVE-2025-48074"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-31T19:23:18Z",
    "nvd_published_at": "2025-08-01T17:15:52Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window.\n\nThe application trusts the value of `dataWindow` size provided in the header of the input file, and performs computations based on this value.\n\nThis may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations.\n\n\n### Details\nA concrete example of this issue is present in the function `readScanline()` in `ImfCheckFile.cpp` at line 235, that performs a for-loop using the `dataWindow min.y` and `max.y` coordinates that can be arbitrarily large.\n\n```cpp\nin.setFrameBuffer (i);\n\nint step = 1;\n\n//\n// try reading scanlines. Continue reading scanlines\n// even if an exception is encountered\n//\nfor (int y = dw.min.y; y \u003c= dw.max.y; y += step) // \u003c-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX\n{\n    try\n    {\n        in.readPixels (y);\n    }\n    catch (...)\n    {\n        threw = true;\n\n        //\n        // in reduceTime mode, fail immediately - the file is corrupt\n        //\n        if (reduceTime) { return threw; }\n    }\n}\n```\n\nAnother example occurs in the `EnvmapImage::resize` function that in turn calls `Array2D\u003cT\u003e::resizeEraseUnsafe` passing the `dataWindow` X and Y coordinates and perform a huge allocation.\n\nOn some system, the allocator will simply return `std::bad_alloc` and crash. On other systems such as macOS, the allocator will happily continue with a \"small\" pre-allocation and allocate further memory whenever it is accessed.\nThis is the case with the `EnvmapImage::clear` function that is called right after and fills the image RGB values with zeros, allocating tens of Gigabytes.\n\n### PoC\n\nNOTE: please download the `oom_crash.exr` file via the following link:\n \nhttps://github.com/ShielderSec/poc/tree/main/CVE-2025-48074\n\n1. Compile the `exrcheck` binary in a macOS or GNU/Linux machine with ASAN.\n2. Open the `oom_crash.exr` file with the following command:\n\n```\nexrcheck oom_crash.exr\n```\n\n3. Notice that `exrenvmap`/`exrcheck` crashes with ASAN stack-trace.\n\n### Impact\nAn attacker could cause a denial of service by stalling the application or exhaust memory by stalling the application in a loop which contains a memory leakage.",
  "id": "GHSA-x22w-82jp-8rvf",
  "modified": "2025-08-01T18:35:51Z",
  "published": "2025-07-31T19:23:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/AcademySoftwareFoundation/openexr/security/advisories/GHSA-x22w-82jp-8rvf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48074"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/AcademySoftwareFoundation/openexr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ShielderSec/poc/tree/main/CVE-2025-48074"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenEXR Out-Of-Memory via Unbounded File Header Values"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…