Br0Nzu

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions prior to 3.2.11 OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** A crafted EXR file with a nonzero `dataWindow.min` can cause the `TypedFlatImageChannel::row()` function to return an invalid heap pointer. This leads to out-of-bounds or use-after-free writes when an application writes rows through the `FlatHalfChannel::row()` function. This issue affects tools, converters, render pipeline components, or image-processing services that process untrusted EXR files using the `FlatHalfChannel::row()` function. **Recommendations** Update to version 3.2.11. Update to version 3.3.13. Update to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions prior to 3.2.11 OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** A heap out-of-bounds write occurs on 32-bit/ILP32 builds when processing a crafted tiled EXR file via the `TiledRgbaInputFile` RGBA API. The issue arises when a file contains a small 40x40 `dataWindow` but a large 65537x65537 tile size, causing the `Array2D<Rgba>` tile-conversion buffer size calculation to overflow. This results in the allocation of an undersized heap buffer, leading to a write operation that exceeds the allocated memory during tile decoding. **Recommendations** Update to version 3.2.11. Update to version 3.3.13. Update to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** A heap out-of-bounds write occurs when the `exrmetrics` tool processes a specially crafted deep scanline EXR file. This happens when using pixel conversion options such as `--pixelmode float` or `--bench`, as the `DeepSlice` function requests FLOAT output while the backing sample buffers are allocated using the input HALF element size. **Recommendations** Update OpenEXR versions 3.3.0 through 3.3.12 to version 3.3.13. Update OpenEXR versions 3.4.0 through 3.4.13 to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXRUtil versions 3.3.0 through 3.3.12 OpenEXRUtil versions 3.4.0 through 3.4.12 **Description** The `TypedDeepImageChannel<T>::row()` API can return an out-of-bounds pointer when a deep image has a non-zero dataWindow origin. This occurs because `ImfDeepImageChannel` utilizes two conflicting coordinate models: `at(x, y)` uses absolute coordinates, while `row(r)` is documented for 0-based logical access. Consequently, if `dataWindow.min` is non-zero, `row(0)` points outside the ` sampleListPointers` allocation rather than the first logical row. This leads to a heap out-of-bounds read and crash, which may allow information disclosure under a controlled heap layout. **Recommendations** Update versions 3.3.0 through 3.3.12 to version 3.3.13. Update versions 3.4.0 through 3.4.12 to version 3.4.13.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions prior to 3.2.11 OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** An issue exists where the `TypedDeepImageChannel::row()` function can return an out-of-bounds pointer when processing a crafted deep EXR image with a nonzero dataWindow origin. This occurs because the API combines zero-based row access with an absolute-coordinate-adjusted base pointer, which may lead to a crash or limited information disclosure. **Recommendations** Update to version 3.2.11. Update to version 3.3.13. Update to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions prior to 3.2.11 OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** On ILP32 builds, an out-of-bounds read occurs when processing a crafted uncompressed deep-tile EXR. This happens because the sample-count table size calculation in OpenEXRCore decoding.c wraps before the `unpack sample table()` function iterates over the attacker-controlled tile dimensions, which can lead to a denial of service. **Recommendations** Update to version 3.2.11. Update to version 3.3.13. Update to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions 3.1.0 through 3.2.10 OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** On ILP32 builds, an out-of-bounds write occurs when processing a crafted B44-compressed scanline EXR. This happens because the logical scratch size truncates before allocation, and the `uncompress b44 impl()` function writes using an attacker-controlled channel width, leading to memory corruption and denial of service. **Recommendations** Update versions 3.1.0 through 3.2.10 to version 3.2.11. Update versions 3.3.0 through 3.3.12 to version 3.3.13. Update versions 3.4.0 through 3.4.13 to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions 3.2.0 through 3.2.10 OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** On ILP32 builds, a heap out-of-bounds read occurs when processing a crafted RLE-compressed EXR image. The issue arises because the 64-bit unpacked size truncates before allocation in OpenEXRCore decoding.c, leading the `unpack 32bit()` function to read beyond the allocated buffer, which can result in a denial of service. **Recommendations** Update versions 3.2.0 through 3.2.10 to version 3.2.11. Update versions 3.3.0 through 3.3.12 to version 3.3.13. Update versions 3.4.0 through 3.4.13 to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions prior to 3.2.11 OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** OpenEXR, the reference implementation for the EXR image format, is subject to a crash when processing a specially crafted EXR file. The issue occurs when the function `Imf::GetChannelsInMultiPartFile()` processes a file with an empty multiView header attribute, leading the function `Imf::viewFromChannelName()` to index an empty vector for a dotless channel name. **Recommendations** Update to version 3.2.11. Update to version 3.3.13. Update to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** The PyOpenEXR Python bindings return stale heap data when reading a specially crafted deep scanline EXR file that utilizes layer-prefixed RGB channels. When using default channel coalescing (where `separate channels` is set to `False`), the wrapper groups channels like left.R, left.G, and left.B into a single RGB sample array. However, the lane-offset calculation in the `setDeepSliceData()` function only recognizes the exact unprefixed names G, B, and A. Consequently, prefixed channels such as left.G and left.B are decoded into lane 0, leaving lanes 1 and 2 uninitialized. A Python application using the default OpenEXR.File API to read untrusted deep EXR files may expose uninitialized same-process heap contents when processing the resulting NumPy sample arrays, while also receiving incorrect green and blue channel data. **Recommendations** Update OpenEXR versions 3.3.0 through 3.3.12 to version 3.3.13. Update OpenEXR versions 3.4.0 through 3.4.13 to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** PyOpenEXR contains a heap buffer overflow triggered by a channel-name key collision between literal and prefixed RGB channels. When the `separate channels` variable is set to false, PyOpenEXR uses the `channelNameToRGBA()` function to map physical channel names and coalesce them into a shared RGB array. A specially crafted flat scanline EXR file containing both a literal channel (e.g., left) and prefixed channels (e.g., left.R, left.G, and left.B) causes a name collision. This leads the wrapper to reuse an undersized two-dimensional NumPy array for the coalesced RGB slices, resulting in an out-of-bounds write when `OpenEXR.File(path)` decodes the pixels. **Recommendations** Update versions 3.3.0 through 3.3.12 to version 3.3.13. Update versions 3.4.0 through 3.4.13 to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** The PyOpenEXR Python bindings contain a heap out-of-bounds write that occurs when reading a specially crafted deep scanline EXR file. The issue arises when a deep file declares a literal channel named `left` alongside layer-prefixed RGB channels `left.R`, `left.G`, and `left.B`. The wrapper allocates a scalar deep sample array for the `left` channel and subsequently reuses it as the destination for the RGB group. Because the deep reader registers sample slices with an RGB stride into storage allocated for a scalar shape, decoding the samples writes past the allocated memory. Triggering this via the public Python API `OpenEXR.File(path)` results in a heap buffer overflow, leading to memory corruption and a crash. **Recommendations** Update versions 3.3.0 through 3.3.12 to version 3.3.13. Update versions 3.4.0 through 3.4.13 to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions prior to 3.2.11 OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** The `exrmultiview` utility can perform a heap out-of-bounds write when combining two valid scanline EXR files if the union `dataWindow` is not aligned to the channel subsampling of one view. The issue occurs because the utility allocates sampled channel storage using a truncated `union width` / `xSampling` and subsequently reads the sampled input through a Slice based on the misaligned union window. This can be triggered during normal processing of crafted but valid input files. **Recommendations** Update to version 3.2.11. Update to version 3.3.13. Update to version 3.4.14.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions prior to 3.2.11 OpenEXR versions 3.3.0 through 3.3.12 OpenEXR versions 3.4.0 through 3.4.13 **Description** The OpenEXRUtil library returns an out-of-bounds pointer from the `SampleCountChannel::row()` API when a deep image has a non-zero `dataWindow` origin. This occurs because the `row()` accessor is 0-based but computes its address from an internal base offset for absolute pixel coordinates, causing a conflict when `dataWindow.min` is non-zero. If a deep image has a large negative vertical origin, `row(0)` points outside the allocated sample-count buffer. An application processing a malicious deep EXR file may perform an out-of-bounds read, potentially leading to a process crash or the disclosure of adjacent heap memory. **Recommendations** Update to version 3.2.11. Update to version 3.3.13. Update to version 3.4.14.