CVE-2026-18495: Libtiff: libtiff: heap-buffer overflow via numeric truncation in the jpeg raw passthrough
A flaw was found in libtiff. A heap-buffer overflow vulnerability exists in the tiff2pdf utility due to an integer truncation error when processing crafted BigTIFF files. An attacker can provide a specially crafted BigTIFF file, causing a 64-bit StripByteCounts value to be truncated to a 32-bit integer. This leads to an undersized memory allocation and a subsequent out-of-bounds memory copy, resulting in a crash and severe memory corruption.
Other sources
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 t2preadwritepdfimage() function.When parsing BigTIFF files, StripByteCounts values are correctly read as 64-bit unsigned integers (uint64t). However, the variable used to track the maximum strip length—maxstriplength—is declared as a 32-bit unsigned integer (uint32t). If an attacker provides a crafted BigTIFF file with a StripByteCounts value exceeding the 32-bit limit, the value is truncated upon assignment to maxstriplength.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 maxstriplength from uint32t to uint64t.
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/-/mergerequests/729
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
libtiffto a version that resolves this vulnerability.Fixed in 4.7.1Patch 67fd283d276f09db54dc39b9ef7b979d4b45c4b1Merge - Upgrade
Upgrade
libtiffto a version that resolves this vulnerability.Fixed in 4.7.1Patch 729
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Deployments that run the tiff2pdf utility and process attacker-supplied BigTIFF files are exposed, particularly when the JPEG raw passthrough path is used. The issue is in the utility rather than being described as a general flaw in every libtiff use case.
What access does an attacker need to exploit this issue?
The supplied severity vector indicates local attack access, low privileges, and required user interaction. The attacker must get a specially crafted BigTIFF file processed by tiff2pdf.
What input characteristics should defensive filtering or review focus on?
The triggering condition involves a BigTIFF file with a 64-bit StripByteCounts value that cannot be safely represented in the 32-bit max_striplength variable. This truncation can cause an undersized allocation followed by a large out-of-bounds copy in the JPEG raw passthrough path.