OpenEXR vulnerabilities

In OpenEXR 2.2.0, a crafted image causes a heap-based buffer over-read in the hufDecode function in IlmImf/ImfHuf.cpp during exrmaketiled execution; it may result in denial of service or possibly unspecified other impact.

In OpenEXR 2.2.0, an invalid write of size 2 in the = operator function in half.h could cause the application to crash or execute arbitrary code.

In OpenEXR 2.2.0, an invalid write of size 1 in the bufferedReadPixels function in ImfInputFile.cpp could cause the application to crash or execute arbitrary code.

In OpenEXR 2.2.0, an invalid write of size 8 in the storeSSE function in ImfOptimizedPixelReading.h could cause the application to crash or execute arbitrary code.

OpenEXR versions from 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.11, and 3.4.0 to before 3.4.11 have an issue with the readVariableLengthInteger() function that decodes a variable-length integer from untrusted EXR input without bounding the shift count. After enough continuation bytes, the code executes a left shift by 70 on a 64-bit value, leading to undefined behavior.

In OpenEXR versions 3.0.0 to before 3.2.9, 3.3.0 to before 3.3.11, and 3.4.0 to before 3.4.11, a vulnerability exists in the IDManifest::init() function. When reconstructing strings from a prefix-compressed representation, the code reads bytes without verifying that the current string has at least two bytes, potentially causing an out-of-bounds read.

OpenEXR before versions 3.2.11, 3.3.13, and 3.4.14 contains a vulnerability in the exrmultiview utility that can write past a heap allocation when combining two attacker-supplied, individually valid scanline EXR files whose union dataWindow is not aligned to one view's channel subsampling. This leads to a heap out-of-bounds write.

PyOpenEXR versions 3.3.0-3.3.12 and 3.4.0-3.4.13 have a heap out-of-bounds write vulnerability when reading a crafted deep scanline EXR file. A specially crafted file with a 'left' channel and layer-prefixed RGB channels can cause a buffer overflow and crash.

OpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13 contain a heap buffer overflow in PyOpenEXR triggered by a channel-name key collision between literal and prefixed RGB channels. A crafted EXR file can cause an out-of-bounds write in a NumPy array during pixel decoding.

OpenEXR versions through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 contain a vulnerability in the OpenEXRUtil library that returns an out-of-bounds pointer from the SampleCountChannel::row() API for deep images with a non-zero dataWindow origin. This can lead to an out-of-bounds read, potentially causing a process crash or disclosure of memory data.

OpenEXR versions 3.4.0-3.4.12 have an out-of-bounds read vulnerability in the HTJ2K decoder because it does not check if the header-length field (PLEN) fits within the available buffer. A crafted EXR file can cause an out-of-bounds read.

PyOpenEXR versions 3.3.0-3.3.12 and 3.4.0-3.4.13 return stale heap data when reading a crafted deep EXR with layer-prefixed RGB channels. Prefixed channels are decoded into wrong lanes, leaving others uninitialized, potentially exposing memory contents.

OpenEXR versions before 3.2.11, 3.3.0-3.3.12, and 3.4.0-3.4.13 have a crash vulnerability when processing a crafted EXR with an empty multiView header attribute. The viewFromChannelName() function indexes an empty vector, leading to a crash.

OpenEXR versions 3.2.0-3.2.10, 3.3.0-3.3.12, and 3.4.0-3.4.13 are vulnerable on ILP32 builds to a heap out-of-bounds read. A crafted RLE-compressed EXR can cause the unpacked size to truncate before allocation, leading to an out-of-bounds read and denial of service.

OpenEXR versions 3.1.0 through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 are vulnerable on ILP32 builds to an out-of-bounds write. When a crafted B44-compressed scanline EXR causes the logical scratch size to truncate before allocation and uncompress_b44_impl() writes using the attacker-controlled channel width, allowing denial of service and memory corruption. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.

OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 are vulnerable on ILP32 builds to an out-of-bounds read. The vulnerability is reached when a crafted uncompressed deep-tile EXR causes the sample-count table size calculation in OpenEXRCore decoding.c to wrap before unpack_sample_table() iterates over the full attacker-controlled tile dimensions, allowing denial of service. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.

OpenEXR versions before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 can return an out-of-bounds pointer from TypedDeepImageChannel::row() when a crafted deep EXR has a nonzero dataWindow origin. This vulnerability occurs because the API combines zero-based row access with an absolute-coordinate-adjusted base pointer, allowing a crash or limited information disclosure. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.

In OpenEXRUtil versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.12, the documented TypedDeepImageChannel<T>::row() API can return an out-of-bounds pointer when a deep image has a non-zero dataWindow origin, resulting in a heap out-of-bounds read and crash, with potential information disclosure under a controlled heap layout. This issue is fixed in versions 3.3.13 and 3.4.13.

OpenEXR versions 3.3.0 through 3.3.12 and 3.4.0 through 3.4.13 are vulnerable to a heap out-of-bounds write when exrmetrics reads a crafted deep scanline EXR. This occurs with pixel conversion options such as --pixelmode float or --bench because DeepSlice requests FLOAT output while the backing sample buffers are allocated using the input HALF element size. The issue is fixed in versions 3.3.13 and 3.4.14.

OpenEXR before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 are vulnerable to a heap out-of-bounds write on 32-bit/ILP32 builds when reading a crafted tiled EXR through the public TiledRgbaInputFile RGBA API. The file uses a small 40x40 dataWindow but a 65537x65537 tile size. On ILP32, the Array2D<Rgba> tile-conversion buffer size calculation overflows, allocates a much smaller heap buffer, and tile decode writes past that allocation. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.

OpenEXR before 3.2.11, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13 allow a crafted EXR with a nonzero dataWindow.min to make TypedFlatImageChannel::row() return an invalid heap pointer, causing out-of-bounds or use-after-free writes. This occurs when an application writes rows through FlatHalfChannel::row(). Affected consumers are tools, converters, render pipeline components, or image-processing services that accept untrusted EXR files and use FlatHalfChannel::row() on loaded images. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.

OpenEXR versions 3.1.0-3.2.10, 3.3.0-3.3.12, and 3.4.0-3.4.13 have an integer overflow in unpack_sample_table(), leading to a read from an invalid memory address and crash when decoding a crafted deep tiled EXR file.

OpenEXR before versions 3.2.10, 3.3.12, and 3.4.13 has an infinite-loop vulnerability in roundListSizeUp() in SampleCountChannel. Supplying UINT_MAX causes the loop to never exit, leading to application hang (denial of service).

OpenEXR versions 3.4.0-3.4.12 have a NULL pointer dereference in exr_attr_set_bytes(). Supplying a positive hint_length with a NULL type_hint causes a deterministic crash, leading to denial of service.

OpenEXR before versions 3.2.10, 3.3.12, and 3.4.13 has a heap out-of-bounds write in SampleCountChannel::set(). An error in Y coordinate calculation can lead to writes before the buffer, potentially causing memory corruption and crashes.

OpenEXR versions 3.4.0-3.4.12 have a reachable assertion failure in the HTJ2K decode path, allowing a crafted HTJ2K-compressed EXR file to cause an unconditional process abort in any application that calls exr_start_read() on untrusted input, resulting in denial of service.

OpenEXR is the reference implementation and specification for the EXR image format, widely used in the motion picture industry. In versions 3.4.0 through 3.4.12, a crafted HTJ2K-compressed EXR file causes an unconditional process abort in any application that calls exr_start_read() on untrusted input, resulting in denial of service. The crash is triggered by a QCD marker whose lower five bits are zero, which OpenEXR passes into the vendored OpenJPH library while constructing the codestream and evaluating its quantization delta parameters. OpenJPH uses an assertion rather than a recoverable error to validate those bits, so any invalid value calls abort() directly and cannot be intercepted by surrounding error handling, a problem compounded by OpenEXR wrapping only its internal HT header parser in error handling while leaving the later codestream read and construction calls unprotected. This issue has been resolved in version 3.4.13.

OpenEXR versions 3.4.0 through 3.4.13 are vulnerable to a crash when decoding crafted HTJ2K-compressed EXR files, due to invalid tile geometry in the OpenJPH AVX2 decoder, causing a stack out-of-bounds write and denial of service. Fixed in 3.4.14.

In OpenEXR versions 3.4.0 through 3.4.11, the HTJ2K decoder function ht_undo_impl() is vulnerable to a heap-buffer-overflow READ. It fails to validate that the tile/line dimensions from the codestream match the EXR header, leading to out-of-bounds reads from the OpenJPH line buffer. A crafted EXR file can cause a deterministic crash (DoS) or leak adjacent heap data.

In OpenEXR library versions 3.0.0 to 3.2.9, 3.3.0 to 3.3.11, and 3.4.0 to 3.4.11, an integer overflow in ImageChannel::resize leads to a heap out-of-bounds write via the OpenEXRUtil public API.

In OpenEXR versions 3.2.0 through 3.2.7, 3.3.0 through 3.3.9, and 3.4.0 through 3.4.9, an integer overflow occurs in the multiplication of image width and height in `internal_dwa_compressor.h:1722`. The missing `(size_t)` cast allows the result to exceed the 32-bit integer range, leading to incorrect buffer size calculation.

In OpenEXR versions 3.2.0 to 3.2.7, 3.3.9, and 3.4.9, a vulnerability exists in the DWA lossy decoder. For sufficiently large image widths, 32-bit arithmetic overflow causes writes outside the allocated rowBlock buffer.

In OpenEXR library versions 3.1.0 through 3.2.6, 3.3.8, and 3.4.8, a vulnerability exists in the internal_exr_undo_piz() function. Signed 32-bit integer arithmetic can overflow and wrap the wavelet pointer, leading to out-of-bounds reads and writes during EXR file decoding.

In OpenEXR versions 3.2.0 through 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute(). When decoding a DWA/DWAB-compressed EXR file with a FLOAT channel, an unaligned row pointer is cast to float*, causing undefined behavior and crashes on alignment-sensitive architectures (ARM, RISC-V).

A vulnerability in OpenEXR (versions 3.4.0 to 3.4.6) allows an attacker to cause a heap overflow by providing a crafted EXR file with HTJ2K compression and a channel width of 32768. Controlled data can be written beyond the output heap buffer, potentially leading to remote code execution.

In the OpenEXR library, a vulnerability exists in the CompositeDeepScanLine::readPixels function where per-pixel totals are accumulated in a vector of unsigned int, allowing an attacker to cause a wrap-around modulo 2^32. This leads to undersized buffer allocation and subsequent buffer overflow during data write operations.