OpenEXR CompositeDeepScanLine integer-overflow leads to heap OOB write

Vulnerability

Overview

In OpenEXR's composite deep image reading path, CompositeDeepScanLine::readPixels accumulates per-pixel sample counts into vector total_sizes using 32-bit arithmetic. An attacker can supply a multipart deep EXR file with very large sample counts across many parts, causing total_sizes[ptr] to wrap modulo 2^32. The subsequently computed overall_sample_count is therefore truncated, leading to an undersized heap buffer is allocated for samples[channel], but decode pointer setup and consumption proceed using the true (unwrapped) sample counts [1][2].

Exploitation

Details

This bug is reachable through standard high-level deep read flow: MultiPartInputFile, DeepScanLineInputPart, and CompositeDeepScanLine. The attacker can use compression features (RLE, ZIPS) of the EXR format allow the attacker to keep the file small while generating extreme decode pressure. Write operations in generic_unpack_deep_pointers (in `src/lib/OpenEXRCore/unpack.c) then write past the undersized composite sample buffer, causing a heap out-of-bounds write [1].

Impact

Successful exploitation leads to heap memory corruption, which can cause a denial of service (crash) or potentially remote code execution in applications that decode attacker-supplied deep EXR images. The vulnerable code path has existed since OpenEXR v2.3.0 [1][2].

Mitigation

The OpenEXR project has released fixed versions: v3.2.6, v3.3.8, and v3.4.6. Users should upgrade to a patched release. No workaround is available for older, unmaintained versions except to avoid processing untrusted deep EXR files [1][2].