An integer overflow in the libtiff rgb2ycbcr utility's cvtRaster() function when computing strip buffer sizes can result in an undersized heap allocation and subsequent heap-based buffer overflow during YCbCr conversion of a crafted TIFF image

An issue in libtiff 85f2ac8e0b01cb7db2bbecf4a3b891bdbef67938 allows an attacker to execute arbitrary code via the processcommandopts() function in tools/tiffcrop.c

The issue happens when decoding Pixarlog codec images with PIXARLOGDATAFMT8BITABGR output format and stride = 3 . The decoder writes 4 output bytes per 3 decoded samples (synthetic alpha byte) but advances the output cursor by 3 bytes. This mismatch causes a linear heap based buffer-overflow of approx. width bytes per scan line. For every 4-bytes in the overflow, the first is always 0x00 while the others are controlled. The overflow happens on a user allocated buffer, but according to the docs (TIFFReadScnaline.rst) the user is supposed to allocate a buffer of this TIFFScanlineSize(t) , which will return the incorrect size. The bug can be pinpointed to two locations in libtiff/tifpixarlog.c - the horizontalAccumulate8abgr function (3->4 byte expansion), and PixarLogDecode which updates the output pointer. RCA PixarLogDecode dispatches on sp->userdatafmt: case PIXARLOGDATAFMT8BITABGR: horizontalAccumulate8abgr(up, llen, sp->stride, (unsigned char )op, sp->ToLinear8); op += llen sizeof(unsigned char); // <-- WRONG for stride=3 break; horizontalAccumulate8abgr with stride == 3 emits 4 bytes per input triplet: if (stride == 3) { op[0] = 0; op[1] = t1; op[2] = t2; op[3] = t3; / 4 bytes written / n -= 3; while (n > 0) { n -= 3; wp += 3; op += 4; / advance 4 per triplet / op[0] = 0; op[1] = …; op[2] = …; op[3] = …; } } So for llen = stride width = 3 W input samples the function writes (llen / 3) 4 = 4 W bytes. PixarLogDecode then advances op by only llen = 3 W. The next iteration starts W bytes before the position where the previous write ended, and on the final iteration the writes extend W bytes past the end of the buffer the caller allocated from TIFFScanlineSize (which is W stride 1 = 3 W bytes for this configuration). Reachability Any application that selects PIXARLOGDATAFMT8BITABGR via TIFFSetField(tif, TIFFTAGPIXARLOGDATAFMT, PIXARLOGDATAFMT8BITABGR) and then reads a PixarLog-compressed TIFF with SamplesPerPixel == 3 is affected. The standard format picker in TIFFRGBAImageBegin does not select 8BITABGR (it picks 8BIT, 16BIT or FLOAT), so TIFFReadRGBAImage is not directly affected. PoC I attached a c program, that when executed produces a file that will overflow a heap buffer by 64 bytes. To verify I compiled it along with ASan-enabled libtiff, and got: $ gcc -fsanitize=address -g -O1 pixarlogheapoverflowpoc.c \ -I$LIBTIFF/libtiff -I$BUILD/libtiff \ -L$BUILD/libtiff -ltiff -Wl,-rpath,$BUILD/libtiff -o poc $ ./poc ================================================================= ==...==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x… at pc 0x… WRITE of size 1 at 0x… thread T0 #0 horizontalAccumulate8abgr libtiff/tifpixarlog.c:470 #1 PixarLogDecode libtiff/tifpixarlog.c:980 #2 TIFFReadScanline libtiff/tifread.c:465 #3 main pocpixarlog8bitabgr.c:31 0 bytes to the right of 192-byte region The 192-byte region is the caller's TIFFScanlineSize-sized buffer (W 3 = 192). The decoder writes 256 bytes ((W 3 / 3) 4 = 256) per row, producing a 64-byte overflow per row. pixarlogheapoverflowpoc.c Fix I didn't open a PR for this fix, since I'm not sure how to make it confidential and I wanted the maintainer to review this issue first. If you want me to open the PR, lmk and I'll do it as instructed. I think that in order to fix, we need to correct the output pointer advancement in PixarLogDecode: case PIXARLOGDATAFMT8BITABGR: horizontalAccumulate8abgr(up, llen, sp->stride, (unsigned char )op, sp->ToLinear8); if (sp->stride == 3) op += (sizet)(llen / 3) 4; / 4 output bytes per triplet / else op += (sizet)llen sizeof(unsigned char); break; And also to somehow make TIFFScanlineSize return the correct size. We can maybe do this with introducing a codec ScanLinesize override that is checked in the function: / tifstrip.c — TIFFScanlineSize64 / if (tif->tifscanlinesizeoverride) return tif->tifscanlinesizeoverride(tif); // ...

Hi,

I would like to disclose CVE-2026-36849, a denial of service vulnerability in libtiff.

== Summary ==

An issue in libtiff v4.7.1 allows an attacker to cause a denial of service via a crafted TIFF file containing a large SamplesPerPixel tag value.

== Affected Versions ==

libtiff v4.7.1 and prior

== Patch ==

https://gitlab.com/gitlab-org/build/omnibus-mirror/libtiff/-/commit/eedba405d3695b52faae65994c5904f228eca0bf

== References ==

- CVE: CVE-2026-36849 - Issue: https://gitlab.com/libtiff/libtiff/-/workitems/781

Regards, Satriyo Utomo (aleens-lab)

A flaw was found in the libtiff library. A remote attacker could exploit a signed integer overflow vulnerability in the putcontig8bitYCbCr44tile function by providing a specially crafted TIFF file. This flaw can lead to an out-of-bounds heap write due to incorrect memory pointer calculations, potentially causing a denial of service (application crash) or arbitrary code execution.

A flaw was found in the libtiff library. A signed integer overflow exists in the putcontig8bitYCbCr44tile function (and potentially similar functions like putcontig8bitYCbCr42tile, putcontig8bitYCbCr22tile, and putcontig8bitYCbCr12tile) within tifgetimage.c. When processing a specially crafted TIFF file with an extremely large width and specific YCbCr subsampling, the calculation for the pointer progression variable (incr) can overflow the 32-bit signed integer boundary. This results in an incorrect negative progression of memory pointers, leading to an out-of-bounds heap write. An attacker could exploit this to cause a denial of service (application crash) or potentially execute arbitrary code.

Last updated 19 August 2026

Last updated 19 August 2026

libtiff up to v4.7.1 was discovered to contain a double free via the component tools/tiffcrop.c.

A flaw was found in Libtiff. This vulnerability is a "write-what-where" condition, triggered when the library processes a specially crafted TIFF image file.

Write-What-Where in libtiff via TIFFReadRGBAImageOriented

The vulnerability resides in the raster decoding logic of libtiff, specifically when processing paletted (indexed color) images with malformed metadata. The function TIFFReadRGBAImageOriented() computes a pointer offset into the raster buffer based on user-controlled image metadata:

raster + (rheight - img.height) rwidth

If the attacker supplies a very large value for img.height (e.g., 0xFFFF) and a valid rheight (e.g., 256), this computation results in a large positive offset, causing the raster pointer (cp) passed into functions like put8bitcmaptile() or put1bitbwtile() to point beyond the bounds of the allocated buffer.

Inside those functions, memory writes occur like this:

cp++ = PALmap[pp][0];

• The write address (cp) is attacker-controlled via the offset calculation from img.height. • The value written (PALmap[pp][0]) is also attacker-controlled: ◦ pp is dereferenced from pixel data in the image file. ◦ PALmap is constructed from the image's color palette, which the attacker also controls. This constitutes a write-what-where vulnerability with a attacker control. Exploitation of a write-what-where primitive can lead to denial of service or code execution through supply of maliciously crafted files.

A flaw has been found in LibTIFF 4.7.0. This affects the function TIFFmallocExt/TIFFCheckRealloc/TIFFHashSetNew/InitCCITTFax3 of the file tools/tiffcmp.c of the component tiffcmp. Executing manipulation can lead to memory leak. The attack is restricted to local execution. This attack is characterized by high complexity. It is indicated that the exploitability is difficult. The exploit has been published and may be used. There is ongoing doubt regarding the real existence of this vulnerability. This patch is called ed141286a37f6e5ddafb5069347ff5d587e7a4e0. It is best practice to apply a patch to resolve this issue. A researcher disputes the security impact of this issue, because "this is a memory leak on a command line tool that is about to exit anyway". In the reply the project maintainer declares this issue as "a simple 'bug' when leaving the command line tool and (...) not a security issue at all".

A weakness has been identified in LibTIFF 4.7.0. This affects the function main of the file tiffcrop.c of the component tiffcrop. Executing manipulation can lead to memory corruption. The attack can only be executed locally. The exploit has been made available to the public and could be exploited.

A vulnerability was determined in LibTIFF up to 4.5.1. Affected by this issue is the function readSeparateStripsetoBuffer of the file tools/tiffcrop.c of the component tiffcrop. The manipulation leads to stack-based buffer overflow. Local access is required to approach this attack. The patch is identified as 8a7a48d7a645992ca83062b3a1873c951661e2b3. It is recommended to apply a patch to fix this issue.

A vulnerability classified as problematic was found in libtiff 4.6.0. This vulnerability affects the function PSLvl2page of the file tools/tiff2ps.c of the component tiff2ps. The manipulation leads to null pointer dereference. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 6ba36f159fd396ad11bf6b7874554197736ecc8b. It is recommended to apply a patch to fix this issue. One of the maintainers explains, that "[t]his error only occurs if DEFERSTRILELOAD (defer-strile-load:BOOL=ON) or TIFFOpen( .. "rD") option is used."

A vulnerability was found in LibTIFF up to 4.7.0. It has been declared as problematic. Affected by this vulnerability is the function t2preadtiffinit of the file tools/tiff2pdf.c of the component fax2ps. The manipulation leads to null pointer dereference. The attack needs to be approached locally. The complexity of an attack is rather high. The exploitation appears to be difficult. The patch is named 2ebfffb0e8836bfb1cd7d85c059cd285c59761a4. It is recommended to apply a patch to fix this issue.

A vulnerability was found in LibTIFF up to 4.7.0. It has been rated as critical. This issue affects the function setrow of the file tools/thumbnail.c. The manipulation leads to buffer overflow. An attack has to be approached locally. The patch is named e8c9d6c616b19438695fd829e58ae4fde5bfbc22. It is recommended to apply a patch to fix this issue. This vulnerability only affects products that are no longer supported by the maintainer.

A vulnerability was found in LibTIFF up to 4.7.0. It has been declared as critical. This vulnerability affects the function gethistogram of the file tools/tiffmedian.c. The manipulation leads to use after free. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The patch is identified as fe10872e53efba9cc36c66ac4ab3b41a839d5172. It is recommended to apply a patch to fix this issue.

A vulnerability was found in LibTIFF up to 4.7.0. It has been declared as critical. This vulnerability affects the function gethistogram of the file tools/tiffmedian.c. The manipulation leads to use after free. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The patch is identified as fe10872e53efba9cc36c66ac4ab3b41a839d5172. It is recommended to apply a patch to fix this issue.

A null pointer dereference flaw was found in Libtiff via tifdirinfo.c. This issue may allow an attacker to trigger memory allocation failures through certain means, such as restricting the heap space size or injecting faults, causing a segmentation fault. This can cause an application crash, eventually leading to a denial of service.

A segment fault (SEGV) flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFReadRGBATileExt() API. This flaw allows a remote attacker to cause a heap-buffer overflow, leading to a denial of service.

A Segment fault (SEGV) problem was found in libtiff that could be triggered by passing a craft tiff file to TIFFReadRGBATileExt() API. In this flaw a remote attackers could cause a Heap-buffer-overflow problem leading to a denial of service.

Reference: https://gitlab.com/libtiff/libtiff/-/issues/622

Fixed at: https://gitlab.com/libtiff/libtiff/-/mergerequests/546

An out-of-memory flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFRasterScanlineSize64() API. This flaw allows a remote attacker to cause a denial of service via a crafted input with a size smaller than 379 KB.

An out-of-memory problem was found in libtiff that could be triggered by passing a craft tiff file to TIFFRasterScanlineSize64() API. In this flaw a remote attackers could cause deny-of-services via a craft input (with size smaller than 379 KB).

Reference: https://gitlab.com/libtiff/libtiff/-/issues/621

Fixed at: https://gitlab.com/libtiff/libtiff/-/mergerequests/553 https://gitlab.com/libtiff/libtiff/-/commit/6791bff9f76c2a7f2f18c80b95c796e93fae6a34

Accounts. The issue was addressed with improved checks.

LibTIFF is vulnerable to a denial of service, caused by an integer overflow in tiffcp.c. By persuading a victim to open a specially crafted tiff image file, a remote attacker could exploit this vulnerability to cause the application to crash.

A vulnerability was found in libtiff due to multiple potential integer overflows in raw2tiff.c. This flaw allows remote attackers to cause a denial of service or possibly execute an arbitrary code via a crafted tiff image, which triggers a heap-based buffer overflow.

An issue was discovered in function TIFFReadDirectory libtiff before 4.4.0 allows attackers to cause a denial of service via crafted TIFF file.

A memory leak flaw was found in Libtiff's tiffcrop utility. This issue occurs when tiffcrop operates on a TIFF image file, allowing an attacker to pass a crafted TIFF image file to tiffcrop utility, which causes this memory leak issue, resulting an application crash, eventually leading to a denial of service.