Advisories for Pypi/OpenEXR package

Function: CompositeDeepScanLine::readPixels, reachable from high-level multipart deep read flows (MultiPartInputFile + DeepScanLineInputPart + CompositeDeepScanLine). Vulnerable lines (src/lib/OpenEXR/ImfCompositeDeepScanLine.cpp): total_sizes[ptr] += counts[j][ptr]; (line ~511) overall_sample_count += total_sizes[ptr]; (line ~514) samples[channel].resize (overall_sample_count); (line ~535) Impact: 32-bit sample-count accumulation wrap leads to undersized allocation, then decode writes with true sample volume, causing heap OOB write in generic_unpack_deep_pointers (src/lib/OpenEXRCore/unpack.c:1374) (DoS/Crash, memory corruption/RCE). Attack scenario: Attacker provides multipart deep EXR with many parts and very large …

When reading a deep scanline image with a large sample count in reduceMemory mode, it is possible to crash a target application with a NULL pointer dereference in a write operation.

The OpenEXR file format defines many information about the final image inside of the file header, such as the size of data/display window. The application trusts the value of dataWindow size provided in the header of the input file, and performs computations based on this value. This may result in unintended behaviors, such as excessively large number of iterations and/or huge memory allocations.

The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a read operation due to bad pointer math when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk.

The OpenEXRCore code is vulnerable to a heap-based buffer overflow during a write operation when decompressing ZIPS-packed deep scan-line EXR files with a maliciously forged chunk header.

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.

In OpenEXR 2.2.0, an invalid read of size 1 in the getBits function in ImfHuf.cpp could cause the application to crash.