GHSA-x22w-82jp-8rvf (CVE-2025-48074)

Details

Summary

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.

Details

A concrete example of this issue is present in the function readScanline() in ImfCheckFile.cpp at line 235, that performs a for-loop using the dataWindow min.y and max.y coordinates that can be arbitrarily large.

in.setFrameBuffer (i);

int step = 1;

//
// try reading scanlines. Continue reading scanlines
// even if an exception is encountered
//
for (int y = dw.min.y; y <= dw.max.y; y += step) // <-- THIS LOOP IS EXCESSIVE BECAUSE OF DW.MAX
{
    try
    {
        in.readPixels (y);
    }
    catch (...)
    {
        threw = true;

        //
        // in reduceTime mode, fail immediately - the file is corrupt
        //
        if (reduceTime) { return threw; }
    }
}

Another example occurs in the EnvmapImage::resize function that in turn calls Array2D<T>::resizeEraseUnsafe passing the dataWindow X and Y coordinates and perform a huge allocation.

On some system, the allocator will simply return std::bad_alloc and crash. On other systems such as macOS, the allocator will happily continue with a "small" pre-allocation and allocate further memory whenever it is accessed. This is the case with the EnvmapImage::clear function that is called right after and fills the image RGB values with zeros, allocating tens of Gigabytes.