AcademySoftwareFoundation OpenEXR SampleCountChannel out-of-bounds read with non-zero dataWindow origins

OpenEXR is the reference implementation and specification for the EXR image file format, widely used in the motion picture industry. In versions through 3.2.10, 3.3.0 through 3.3.12, and 3.4.0 through 3.4.13, the OpenEXRUtil library returns an out-of-bounds pointer from the SampleCountChannel::row() API when a deep image has a non-zero dataWindow origin. The row() accessor is documented as 0-based and computes its address from an internal base that is offset for absolute pixel coordinates, so the two coordinate models conflict whenever dataWindow.min is non-zero. For a deep image whose data window has a large negative vertical origin, row(0) points far outside the allocated sample-count buffer. An application that opens an attacker-controlled deep EXR file and accesses sample counts through row() performs an out-of-bounds read, which can crash the process or, under a controlled heap layout, return adjacent heap memory as sample-count values. This issue is fixed in versions 3.2.11, 3.3.13, and 3.4.14.

• AcademySoftwareFoundation openexr 2.x, 3.0.x, and 3.1.x are listed as affected by the vendor advisory.
• 3.2 branch: 3.2.0 through 3.2.10 are affected; the listed fix is 3.2.11.
• 3.3 branch: 3.3.0 through 3.3.12 are affected; the listed fix is 3.3.13.
• 3.4 branch: 3.4.0 through 3.4.13 are affected; the listed fix is 3.4.14.
• The status of branches not explicitly listed in the reviewed sources, including later release branches, is not established and should not be inferred as unaffected.

The flaw is a CWE-125 out-of-bounds read in OpenEXRUtil, specifically the SampleCountChannel::row() API. The API is documented as 0-based row access, but the implementation calculates the pointer from _base, which is adjusted for absolute pixel-coordinate access. When dataWindow.min is non-zero, those coordinate models conflict: at(dataWindow.min.x, dataWindow.min.y) can address the intended data, while row(0) can point outside the allocation backing _numSamples. An attacker-controlled deep EXR can provide a data window with a large negative vertical origin, causing sample-count access to read outside the heap buffer. The vulnerable read occurs when an application opens the file and accesses sample counts through SampleCountChannel::row(). The available evidence confirms a heap out-of-bounds read; it does not establish an out-of-bounds write or code-execution primitive for this issue.

An attacker must supply a crafted deep EXR file to an application and cause that application to open or decode it. The supplied exploitability properties indicate that authentication and special privileges are not required, but user or service interaction with the file is required. The file may be delivered over a network when the target application accepts remote input, but the flaw is reached only when the affected decoding path processes it. The vendor advisory publishes reproducible PoC files demonstrating a crash and a controlled-heap case where adjacent heap data can become observable. The available evidence establishes a public PoC, but does not establish in-the-wild exploitation, a named campaign, or a specific victim.

The direct technical outcome is a heap out-of-bounds read when caller code accesses sample counts through SampleCountChannel::row(). The most immediate consequence is a crash in the decoding process, which can reduce the availability of a worker or service. With a controlled heap layout, the read may return adjacent words and create a limited confidentiality impact. The flaw does not require a change in security scope, and the available evidence does not establish a memory-write or code-execution primitive. A system is exposed only when an attacker-controlled deep EXR reaches the affected code path.

• A crafted EXR file can crash an image-decoding worker or service, interrupting image-processing pipelines.
• When the heap layout is favorable, data adjacent to the sample-count buffer may be returned to the caller and become observable, creating a limited information-disclosure risk.
• Actual exposure depends on whether the organization accepts untrusted EXR files and reaches the affected SampleCountChannel::row() code path.
• The evidence for this issue does not show data modification or a specific breach scenario. The confirmed organisational consequences are service interruption and possible limited disclosure from the decoder process.

1. Upgrade openexr to the confirmed fixed release for the deployed branch: 3.2.11 for the 3.2 branch, 3.3.13 for the 3.3 branch, or 3.4.14 for the 3.4 branch.
2. For systems running 2.x, 3.0.x, or 3.1.x, the advisory confirms exposure but does not provide a same-branch fixed release. Move to a vendor-confirmed fixed release after compatibility testing.
3. Check and redeploy every application, worker, and utility that may carry its own OpenEXRUtil copy, not only the host operating system package.
4. If an immediate upgrade is not possible, prevent affected components from processing untrusted deep EXR files or isolate the decoder from sensitive data and privileges. This is a temporary risk-reduction measure, not a vendor-confirmed fix.

• Inventory applications, services, and tools that use OpenEXR or OpenEXRUtil to open deep EXR files, including copies bundled with an application.
• Review dependency and code usage for SampleCountChannel::row() calls on deep images, especially when processing files whose dataWindow does not start at zero.
• In an isolated test environment, exercise the file-opening path with the PoC supplied by the vendor advisory and enable AddressSanitizer or UndefinedBehaviorSanitizer to identify the out-of-bounds read.
• Review crash telemetry and decoder logs for SIGSEGV or sanitizer reports occurring during sample-count processing. These are supporting investigation signals, not issue-specific IOCs, and their absence does not prove that a system is safe.
• Verify the deployed version of each binary or package after remediation rather than relying only on the version recorded by the build system.