GHSA-qhpm-86v7-phmm

### Summary 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. ### Details In the `ScanLineProcess::run_fill` function, implemented in `src/lib/OpenEXR/ImfDeepScanLineInputFile.cpp`, the following code is used to write the `fillValue` in the sample buffer: ```cpp switch (fills.type) { case OPENEXR_IMF_INTERNAL_NAMESPACE::UINT: { unsigned int fillVal = (unsigned int) (fills.fillValue); unsigned int* fillptr = static_cast<unsigned int*> (dest); for ( int32_t s = 0; s < samps; ++s ) fillptr[s] = fillVal; // <--- POTENTIAL CRASH HERE break; } ``` However, when `reduceMemory` mode is enabled in the `readDeepScanLine` function in `src/lib/OpenEXRUtil/ImfCheckFile.cpp`, with large sample counts, the sample data will not be read, as shown below: ```cpp // limit total number of samples read in reduceMemory mode // if (!reduceMemory || fileBufferSize + bufferSize < gMaxBytesPerDeepScanline) // <--- CHECK ON LARGE SAMPLE COUNTS AND reduceMemory { // SNIP... try { in.readPixels (y); } ``` Therefore, in those cases, the sample buffer would not be allocated, resulting in a potential write operation on a NULL pointer. ### PoC NOTE: please download the `runfill_crash.exr` file from the following link: https://github.com/ShielderSec/poc/tree/main/CVE-2025-48073 1. Compile the `exrcheck` binary in a macOS or GNU/Linux machine with ASAN. 2. Open the `runfill_crash.exr` file with the following command: ``` exrcheck -m runfill_crash.exr ``` 3. Notice that `exrcheck` crashes with ASAN stack-trace. ### Impact An attacker may cause a denial of service by crashing the application.