OpenEXR Memory Corruption and Assertion Failures

NULL pointer dereference in OpenEXR 3.4.0-3.4.12 causes a deterministic crash in the OpenEXRCore C API function `exr_attr_set_bytes()` when a caller passes a positive `hint_length` alongside a NULL `type_hint` pointer, enabling reliable denial of service against any application that processes EXR content via this API. The flaw is confined to availability impact with no confidentiality or integrity exposure, and the CVSS 4.0 local attack vector limits remote exploitation to indirect paths such as network-facing EXR parsing pipelines. No public exploit code or active exploitation has been identified; a vendor-released patch is available in version 3.4.13.

Infinite-loop denial of service in OpenEXR versions prior to 3.2.10, 3.3.12, and 3.4.13 allows an attacker to permanently hang any process that parses a crafted EXR image by triggering an integer overflow in the sample-count helper roundListSizeUp(). When UINT_MAX is passed as a sample-count value, 32-bit unsigned left-shift arithmetic wraps the accumulator to zero, producing a loop condition that never terminates. The vulnerability is reachable through public OpenEXRUtil APIs, making it exploitable wherever applications accept externally-supplied EXR files. No public exploit code or CISA KEV listing has been identified at time of analysis.

Heap out-of-bounds write in OpenEXR's DeepImage API affects all versions prior to 3.2.10, 3.3.12, and 3.4.13, exploitable by processing a crafted deep image EXR file. A coordinate axis confusion bug in `Imf_4_0::SampleCountChannel::set()` uses `dataWindow.min.x` instead of `dataWindow.min.y` when computing a target Y coordinate, causing memory writes before the allocated `_numSamples` heap buffer when `min.x ≠ min.y`. No public exploit identified at time of analysis; SUSE Linux Enterprise distributions have received vendor-released patches confirming active remediation.

Integer overflow in OpenEXR's deep tiled image decoder crashes any application that opens a crafted EXR file, affecting versions 3.1.0 through 3.4.13 across all three maintained release branches. The overflow occurs in OpenEXRCore's unpack_sample_table() function during the standard exr_decoding_run path, meaning no non-default configuration is required - only that the file uses the deep tiled variant of the format. Impact is denial of service via crash (no code execution demonstrated); no public exploit code exists and this vulnerability is not listed in CISA KEV.

Denial of service in OpenEXR 3.4.0 through 3.4.12 allows any application calling exr_start_read() on untrusted input to be unconditionally aborted by a crafted HTJ2K-compressed EXR file containing a QCD marker with lower five bits set to zero. The flaw chains two weaknesses: OpenJPH's vendored assertion-based validation calls abort() instead of returning a recoverable error, and OpenEXR's error handling wraps only its internal HT header parser, leaving downstream codestream construction calls entirely unprotected. No public exploit or active exploitation (CISA KEV) has been identified, but the trivial triggering condition and prevalence of OpenEXR in automated rendering pipelines make this a meaningful denial-of-service risk for media production infrastructure.