An AddressSanitizer (ASan)-confirmed heap-buffer overflow exists in the tiff2pdf
utility of libtiff (tested on version 4.5.0). The vulnerability is triggered
during the processing of crafted BigTIFF files, leading to a massive
out-of-bounds memory copy that causes a crash and presents a severe memory
corruption risk.

Technical Details

The root cause is an integer truncation flaw located in the JPEG raw passthrough
path within tools/tiff2pdf.c, specifically in the t2p_readwrite_pdf_image()
function.When parsing BigTIFF files, StripByteCounts values are correctly read
as 64-bit unsigned integers (uint64_t). However, the variable used to track the
maximum strip length—max_striplength—is declared as a 32-bit unsigned integer
(uint32_t). If an attacker provides a crafted BigTIFF file with a
StripByteCounts value exceeding the 32-bit limit, the value is truncated upon
assignment to max_striplength.This truncation results in an undersized heap
allocation. Subsequently, TIFFReadRawStrip(..., -1) attempts to copy the full
64-bit strip byte count into this inadequate buffer, resulting in a heap-based
buffer overflow that can exceed 4GB.

Affected VersionsVulnerable:

libtiff versions 3.9.0 through 4.7.0.

Fixed: libtiff version 4.7.1.

Upstream Status and RemediationUpstream developers have addressed this issue in
version 4.7.1 by changing the data type of max_striplength from uint32_t to
uint64_t.

Note for Downstream Maintainers: The upstream libtiff project policy focuses on
maintaining the current source tree and issuing new releases rather than
backporting patches to legacy versions.

Commit: https://gitlab.com/libtiff/libtiff/-/commit/67fd283d276f09db54dc39b9ef7b979d4b45c4b1Merge
Request (!729): https://gitlab.com/libtiff/libtiff/-/merge_requests/729