The execution reproduced a segmentation fault caused by an invalid memory read. The AddressSanitizer stack trace identified the failure during a memmove operation called from TIFFReadRGBATileExt.

Root Cause Analysis

Using GDB, the crash condition was reproduced with the following runtime values:

The vulnerable code then executed:

With the observed values, this calculation is:

Because read_ysize is unsigned, the result wrapped to:

which is UINT32_MAX.

The value of read_ysize was later used in the source pointer calculation for memmove.

Immediately before the failing memmove, GDB showed:

The destination pointer evaluated to:

which was the start of the raster buffer.

The source pointer evaluated to:

The calculated source pointer was 17179869176 bytes, approximately 16 GiB, beyond the start of the raster buffer.

Executing the memmove in GDB resulted in:

The backtrace showed the following crash path:

This confirms that the unsigned underflow in read_ysize produced an out-of-bounds source offset. The resulting invalid source pointer was then used by memmove, causing an invalid memory read and a segmentation fault.

Patch Analysis and Fix Validation

The upstream fix added an explicit bounds check before the vulnerable read_ysize calculation:

Using GDB on the fixed version, the following runtime values were observed:

For these values, the new validation condition evaluates to true because:

The function therefore reported:

and returned 0.

As a result, execution did not reach the vulnerable calculation:

This prevents the unsigned underflow observed in the vulnerable version and stops the invalid value from being used in the later memmove source pointer calculation.

Reproducer Analysis and Preconditions

The original reproducer incorrectly calculates the number of tiles along the Y axis.

The relevant code passes the return value of TIFFGetField() directly as the Y coordinate to TIFFComputeTile():

Using GDB, tile_height was observed to contain:

However, TIFFGetField() returned:

The return value indicates success; it is not the image height. Therefore, the call effectively becomes:

For this TIFF, GDB showed that this call returns:

This value is a tile index, not the number of tiles along the Y axis.

The original reproducer then used this value in its calculation of num_tiles_y, resulting in:

However, the image dimensions and tile dimensions are:

Therefore, the correct number of tiles along the Y axis is:

The incorrect value of 63 causes the loop to iterate with Y values from 0 through 62, even though the image height is 33 and the valid Y coordinates are only 0 through 32.

This allows an invalid value such as:

to be passed to TIFFReadRGBATileExt.

The vulnerable libtiff version did not reject this out-of-range coordinate before performing the unsigned img.height - row calculation. This allowed the invalid API input generated by the reproducer to become a memory-safety failure.

The maintainer-provided corrected reproducer calculates the number of tiles directly from the image and tile dimensions.

For the same TIFF, the corrected calculation produces:

The corrected reproducer was tested against the same vulnerable libtiff build and the same trigger file.

The program exited with status 0, and no AddressSanitizer or SIGSEGV report was produced.

This supports the maintainer's observation that the original reproducer contains an incorrect tile-count calculation. However, the vulnerable libtiff version still lacked defensive row and column validation, allowing invalid API coordinates to result in a memory-safety failure.

Validation Summary

Conclusion

The crash in TIFFReadRGBATileExt occurs when an out-of-range image coordinate reaches the vulnerable libtiff implementation.

In the original reproducer, an incorrect tile-count calculation causes num_tiles_y to be calculated as 63 instead of the correct value 33. As a result, the reproducer can pass a row outside the valid image range to TIFFReadRGBATileExt.

In the vulnerable libtiff version, the row and column arguments were not validated before the calculation:

For the reproduced case, row was 34 while img.height was 33. Because read_ysize is unsigned, the subtraction underflowed to UINT32_MAX. This value was subsequently used in the source pointer calculation for memmove, producing an invalid memory read and a segmentation fault.

The upstream fix adds explicit row and column bounds validation before this calculation. Testing the fixed build confirmed that the same invalid coordinate is rejected before the underflow and memmove can occur.

The maintainer-provided corrected reproducer was also tested against the vulnerable build using the same TIFF file. It calculated the correct tile count and completed without an AddressSanitizer or SIGSEGV report.

Therefore, this analysis does not establish that the TIFF file alone triggers the memory-safety failure when the API is used correctly. The original reproducer contains an incorrect tile-count calculation, while the historical libtiff implementation lacked defensive bounds validation and allowed the resulting invalid API input to become a memory-safety failure.