OpenEXR's Unbounded File Header Values can Lead to Out-Of-Memory Errors

Vulnerability

Overview

OpenEXR (version 3.3.2) trusts unvalidated dataWindow size values from the header of an EXR file. The library performs computations based on these values without proper bounds checking, leading to excessive memory allocation and performance degradation. This issue is documented in the NVD entry [1] and the GitHub security advisory [3].

Exploitation

Details

The root cause is the absence of validation of the dataWindow dimensions before they are used in operations such as loops and memory allocations. As described in the advisory [3], functions like readScanline() in ImfCheckFile.cpp run a for loop from dw.min.y to dw.max.y—an attacker can set dw.max.y to an arbitrarily large value, causing an excessive number of iterations. Similarly, the EnvmapImage::resize function passes dataWindow coordinates to Array2D::resizeEraseUnsafe, resulting in huge memory allocations. On some systems, this triggers std::bad_alloc and crashes; on others (e.g., macOS), the allocator defers allocation, leading to tens of gigabytes of memory consumption when the image data is subsequently filled with zeros [3]. The advisory provides a proof-of-concept file (oom_crash.exr) to reproduce the crash [3][4].

Impact

An attacker can craft a malicious EXR file with inflated dataWindow values to cause a denial-of-service (DoS) condition. The impact is limited to resource exhaustion—excessive CPU time and memory allocation—that can stall or crash the application processing the file. The advisory [3] notes that the vulnerability does not lead to arbitrary code execution, only a DoS.

Mitigation

The vulnerability is fixed in OpenEXR version 3.3.3 [1]. Users should upgrade to the latest version. If upgrading is not immediately possible, avoid opening untrusted EXR files, though no workaround is provided beyond validation of input files or restricting access to the library.