Security
Headlines
HeadlinesLatestCVEs

Headline

GHSA-qhpm-86v7-phmm: OpenEXR ScanLineProcess::run_fill NULL Pointer Write In "reduceMemory" Mode

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:

                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:

            // 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
  1. Notice that exrcheck crashes with ASAN stack-trace.

Impact

An attacker may cause a denial of service by crashing the application.

ghsa
#mac#linux#dos#git

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:

            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:

        // 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

  1. Notice that exrcheck crashes with ASAN stack-trace.

Impact

An attacker may cause a denial of service by crashing the application.

References

  • GHSA-qhpm-86v7-phmm
  • https://github.com/ShielderSec/poc/tree/main/CVE-2025-48073

ghsa: Latest News

GHSA-qc2h-74x3-4v3w: MaterialX Lack of MTLX Import Depth Limit Leads to DoS (Denial-Of-Service) Via Stack Exhaustion