CVE-2026-112404: Pillow: OOB read in TiffDecode.c tile and RGBA paths leaks heap memory into pixels

============================================================================ OOB read in TiffDecode.c tile and RGBA paths leaks heap memory into pixels Location: src/libImaging/TiffDecode.c:483 in decodeTile() Commit: a707c6b21c313880d0771e54965d142dd42358b6 ============================================================================

Pillow reads past the end of a heap buffer when decoding certain malformed compressed TIFF files, and copies the bytes it reads into the pixels of the image it returns. An attacker who can get an application to open and load an image file, for example by uploading it to a service that returns thumbnails, previews or converted images, gets back fragments of that process's heap memory, including pointer values. A slightly larger file instead crashes the process. No special settings are needed, and nothing is written out of bounds.

The bug is in decodeTile() and decodeAsRGBA() in src/libImaging/TiffDecode.c. Both size their decode buffer from libtiff's view of the pixel layout (TIFFTileSize()/TIFFTileRowSize(), or img.width 4). They then unpack each row with the unpacker that TiffImagePlugin.setup() chose from Pillow's own parse of the directory, and neither checks that the unpacker's input row fits inside the row libtiff produced. decodeStrip() has exactly this check, added for OSS-Fuzz crash-0da0 in 8.2.0, but the tile and RGBA paths never got it.

The two parsers can be made to disagree with a duplicated PhotometricInterpretation or BitsPerSample tag, because libtiff keeps the first occurrence and Pillow keeps the last. Pillow then unpacks 4 to 8 bytes per pixel from rows that libtiff filled with 1 to 4 bytes, so the last rows of each tile are read from beyond the buffer. The disclosed memory is a few tile rows past the buffer, and the attacker chooses the tile width. The amount does not grow with the number of tiles, because the buffer is reused for every tile.

The tile half was introduced in 1c295bf43 (first released in 8.2.0). The RGBA half was introduced in eb8c1206d, the CVE-2020-35654 fix (8.1.0).

The attached reproducer runs against an unmodified build. It writes three roughly 400-byte files that load without error, yet the last pixel rows of each change with glibc's malloc fill pattern and contain heap pointer bytes. A fourth file with a 65536x16 tile segfaults in copy4 ← decodeTile (TiffDecode.c:483) in most runs, depending on what is mapped after the buffer.

Details

decodeTile() and decodeAsRGBA() in src/libImaging/TiffDecode.c size state->buffer from what libtiff says it will produce (TIFFTileSize(), resp. img.width 4), but unpack each row with the shuffler that TiffImagePlugin.setup() selected from Pillow's own parse of the IFD. Nothing in either function checks that the unpacker's input row (width state->bits / 8 bytes) fits inside the row libtiff wrote. decodeStrip() has exactly that check; the other two do not. Whenever the two IFD parsers disagree about the pixel layout — a tag with the wrong count or type that libtiff ignores but Pillow accepts, or a duplicated PhotometricInterpretation/BitsPerSample/SamplesPerPixel entry (libtiff keeps the first occurrence, ImageFileDirectoryv2.load() the last) — the unpacker reads past the end of the heap buffer and the bytes it reads become pixels of the returned image. Any Pillow rawmode wider than libtiff's actual sample layout works (RGBX, RGB;16N, RGBA;16N, I;32, F;32F, …); RGBA;16N (64 bits/pixel) against 1-bit libtiff data is the largest ratio, where every row after the first of each tile is read almost entirely from beyond the buffer.

The ~400-byte TIFF tilecount2.tif generated by the reproducer — one 16x16 tile, BitsPerSample 8, SamplesPerPixel 1, Compression 8 (Adobe Deflate), and PhotometricInterpretation written as a SHORT with count 2 (6, 6) — is opened by Image.open() as mode RGB with libtiff rawmode RGBX, and load() succeeds on the stock build. Rows 13–15 of the result contain bytes that lie 16, 32 and 48 bytes past the 256-byte tile buffer: decoding the same file twice under MALLOCPERTURB=85 and =170 yields identical rows 0–12 and different bytes in rows 13–15 (aa vs 55, i.e. glibc's fill pattern). Under an ASan build of the extensions the same load() reports heap-buffer-overflow READ of size 64 in copy4 (src/libImaging/Unpack.c:1290) called from src/libImaging/TiffDecode.c:483, against the 256-byte region allocated at TiffDecode.c:448. The same layout with a single 65536x16 tile (4.5 KB file) makes the stock build SIGSEGV in copy4 ← decodeTile reading an unmapped address in most runs (whether it faults depends on what is mapped after the 1 MiB buffer; a wider tile makes it reliable).

Why the two parsers disagree

libtiff 4.5 rejects a PhotometricInterpretation entry whose count is not 1 (TIFFFetchNormalTag: Incorrect count for "PhotometricInterpretation"; tag ignored), so for this file TIFFGetField(tiff, TIFFTAGPHOTOMETRIC, …) returns 0 and libtiff treats the data as one 8-bit sample per pixel: TIFFTileSize() = 256, TIFFTileRowSize() = 16.

Pillow keeps the first value and carries on:

python src/PIL/TiffImagePlugin.py:762-770 (ImageFileDirectoryv2.setitem, reached from load()) try: (dest[tag],) = values except ValueError: # We've got a builtin tag with 1 expected entry warnings.warn(f"Metadata Warning, tag {tag} had too many entries: ...") dest[tag] = values[0]

so setup() sees photo == 6. OPENINFO[(II, 6, (1,), 1, (8,), ())] is ("L", "L"), and because the file is compressed the libtiff branch then overrides the rawmode:

python src/PIL/TiffImagePlugin.py:1578, 1600-1607 self.useloadlibtiff = READLIBTIFF or self.compression != "raw" … if photo == 6: self.mode = "RGB" if self.compression in "jpeg" and self.planarconfiguration == 1: rawmode = "RGB" else: rawmode = "RGBX"

RGBX is a 32-bit rawmode, so getunpacker() (src/decode.c:301-309) sets state->bits = 32 and state->shuffle = copy4. The intent of the photo == 6 override is that libtiff will deliver RGBA through TIFFRGBAImage, but that decision is made in C from libtiff's reading of the tag, which here is "not YCbCr":

c // src/libImaging/TiffDecode.c:737-764 TIFFGetField(tiff, TIFFTAGPHOTOMETRIC, &photometric); // unset -> stays 0 … readAsRGBA = photometric == PHOTOMETRICYCBCR; // 0 … if (TIFFIsTiled(tiff)) { decodeTile(im, state, tiff, planes, unpackers); // unpackers[0] = copy4

The missing check

decodeTile() only guards against libtiff's tile being larger than what the unpacker expects, then allocates exactly TIFFTileSize() bytes and feeds rowbytesize-strided rows to the shuffler:

c // src/libImaging/TiffDecode.c:403-487 (decodeTile) tilebytessize = TIFFTileSize(tiff); // 256 … rowbytesize = TIFFTileRowSize(tiff); // 16 … if (tilebytessize > ((tilelength state->bits / planes + 7) / 8) tilewidth) { // 256 > 1024 is false -> no abort … } state->bytes = tilebytessize; newdata = realloc(state->buffer, state->bytes); // 256-byte buffer (line 448) … for (tiley = 0; tiley < currenttilelength; tiley++) { shuffler( // copy4: reads currenttilewidth4 = 64 bytes (UINT8 )im->image[tiley + y] + x im->pixelsize, state->buffer + tiley rowbytesize, // from offset 16tiley currenttilewidth );

Row tiley is read from [16·tiley, 16·tiley + 64); for tiley = 13, 14, 15 that ends 16, 32, 48 bytes past the 256-byte allocation. In general the last rows of every tile over-read by up to (state->bits / libtiffbitsperpixel − 1) × rowbytesize bytes, and rowbytesize scales with the attacker-chosen TileWidth.

Note also that the existing one-sided check at line 434 multiplies the file-controlled tilewidth/tilelength (UINT32, accepted up to INTMAX at line 428) by state->bits in 32-bit unsigned arithmetic, so tilewidth state->bits wraps for tilewidth ≥ 2^32 / bits (2^26 for the 64-bit rawmodes, 2^27 for RGBX/I;32/F;32F). An 8 KB file declaring a 2,097,152×1 image with TILEWIDTH = 2^26+16, TILELENGTH = 1, 1-bit data for libtiff and RGBA;16N for Pillow makes libtiff allocate an ~8 MB tile from which unpackRGBA16L reads 16 MB, and the stock build SIGSEGVs in unpackRGBA16L ← decodeTile (TiffDecode.c:483); a row-size comparison written in the same 32-bit arithmetic as line 434 would evaluate that row to 128 bytes and still accept it, so the new check must be done in a 64-bit type.

Compare the strip path, which refuses this situation (added for OSS-Fuzz crash-0da0 in 8.2.0):

c // src/libImaging/TiffDecode.c:528-548 (decodeStrip) unpackerrowbytesize = (state->xsize state->bits / planes + 7) / 8; … rowbytesize = TIFFScanlineSize(tiff); // if the unpacker calculated row size is > row byte size, (at least) the last // row of the strip will have a read buffer overflow. if (rowbytesize == 0 || unpackerrowbytesize > rowbytesize) { state->errcode = IMAGINGCODECBROKEN; return -1; }

The identical file written with one strip instead of one tile fails load() with OSError: decoder error -2 because of this check.

Same gap in decodeAsRGBA()

decodeAsRGBA() always produces img.width 4 bytes per row (TiffDecode.c:325, buffer allocated at line 339) and unpacks with state->shuffle (line 373) without looking at state->bits. It is reached when libtiff sees YCbCr while Pillow does not force RGBX. libtiff marks later duplicates of a tag as ignored (first occurrence wins); Pillow's ImageFileDirectoryv2.load() overwrites (TiffImagePlugin.py:945, last wins). The reproducer's ycbcrdup.tif is a 16x16 Deflate strip with PhotometricInterpretation present twice (6, then 2) and BitsPerSample twice (8,8,8, then 16,16,16): libtiff decodes 8-bit YCbCr into a 1024-byte RGBA raster, Pillow selects RGB;16N (state->bits = 48), and unpackRGB16L reads 96 bytes per 64-byte row — ASan reports heap-buffer-overflow in unpackRGB16L (Unpack.c:609) from TiffDecode.c:373, past the 1024-byte region from TiffDecode.c:339.

The count-2 encoding is not the only lever, and on released versions it is not a lever at all: a 1-sample photo == 6 file only gets rawmode RGBX since the unreleased commit 155330d63 ("Do not open YCbCr colorspace images as RGB without libtiff (#9779)", 2026-08-26). Released versions are reached through duplicated tags instead. A 3-sample tiled file with two PhotometricInterpretation entries (1 or 2, then 6) produces the same copy4 ← decodeTile over-read, since libtiff keeps the first value and decodes 3 bytes per pixel while Pillow keeps 6 and unpacks 4 (the reproducer's tiledup.tif). ycbcrdup.tif above reaches decodeAsRGBA() the same way.

Impact

Any application that calls Image.open() + load() (or thumbnail(), convert(), save(), …) on an untrusted file reaches this with default settings: the file is content-sniffed as TIFF, and any compressed TIFF is decoded through libtiff and TiffDecode.c without READLIBTIFF being set. The over-read bytes are copied into the image's pixel rows, so a service that returns a thumbnail, preview or converted image hands adjacent heap memory back to the uploader, heap pointer values included — up to three libtiff tile rows past the buffer for the RGBX-over-8-bit case, with the tile row length (TileWidth) chosen by the attacker. state->buffer is allocated once and reused for every tile, so each tile re-reads the same region past that one buffer; the distinct heap disclosed per image is about (unpackerbpp / libtiffbpp − 1) tile rows and does not grow with the tile count. With a wide tile the read runs off the mapping and the process segfaults instead (the 65536x16 case crashes the stock build in most runs, depending on what is mapped after the buffer), taking down the whole worker rather than one request. Writes go to the correctly sized Imaging rows, so this is disclosure / crash, not memory corruption.

This is the same family as CVE-2020-35654 (Pillow and libtiff interpreting a YCbCr IFD differently in TiffDecode.c); that fix and the later crash-0da0 fix closed the write and the strip-path read, but the tile path and the RGBA path still trust Pillow's rawmode over libtiff's row size. The tile-path gap was introduced in 1c295bf43c3a ("Check for dimensions and sizes to fit into int", 2021-01-25), which switched decodeTile() from a buffer sized by Pillow's unpacker to TIFFTileSize()/TIFFTileRowSize(); it is first in Pillow 8.2.0. The decodeAsRGBA() half dates from eb8c1206d6b1 ("Fix CVE-2020-35654 - OOB Write in TiffDecode.c"), first in 8.1.0.

Reproducing

Run repro (a single Python 3 script) against the installed, unmodified Pillow. No sanitizer build is needed. It writes four TIFFs into a temporary directory, decodes each one in a child process, and removes the directory at the end.

The script writes its TIFFs byte by byte with a small classic-TIFF writer. Each file has a single IFD and a single Deflate-compressed block. Deflate is only there so the file is decoded by libtiff and TiffDecode.c. Every pixel byte in the compressed data is defined, so the decoded image should not depend on anything else in the process:

- tilecount2.tif: a 16x16, 1-sample, 8-bit tile with PhotometricInterpretation written as SHORT count 2, (6, 6). Pillow keeps 6 and unpacks with copy4 (RGBX, 4 bytes per pixel). libtiff ignores the tag and decodes 1 byte per pixel. This lever needs 155330d63 (unreleased). - tiledup.tif: a 16x16, 3-sample, 8-bit tile with PhotometricInterpretation present twice, 2 then 6. libtiff keeps 2 (RGB, 3 bytes per pixel) and Pillow keeps 6 (RGBX, 4 bytes per pixel). This variant also applies to released versions. - ycbcrdup.tif: the 16x16 strip with BitsPerSample 8,8,8 then 16,16,16 and PhotometricInterpretation 6 then 2. libtiff decodes 8-bit YCbCr through decodeAsRGBA() (4 bytes per pixel), and Pillow unpacks RGB;16N with unpackRGB16L (6 bytes per pixel). - tilebig.tif: the tilecount2.tif layout with a single 65536x16 tile.

For each of the first three files, the script runs Image.open() + load() + tobytes() twice, once with MALLOCPERTURB=85 and once with =170. If the two outputs differ, bytes from beyond the decode buffer have become pixels. In that case it prints the first differing offset and the bytes around it from both runs. On this tree all three differ in their last rows: the aa/55 fill bytes show up, along with heap pointer bytes. The script then decodes tilebig.tif and checks for a SIGSEGV (exit status -11). If gdb is available, it prints the top frames: copy4 (Unpack.c:1290) ← decodeTile (TiffDecode.c:483) ← ImagingLibTiffDecode. This crash depends on ASLR, so an occasional run may survive.

Each step prints which imaging build it used and how Pillow opened the file (mode, size and rawmode). The script ends with a one-line summary. The last line is BUG if any file leaked heap bytes into its pixels or the big tile crashed the process. Otherwise it is OK.

Suggested fix

The attached patch restores the decodeStrip() invariant (the unpacker's input row must fit inside libtiff's row) in the two sibling decoders in src/libImaging/TiffDecode.c, at the point where each one sizes its buffer:

- decodeTile() computes unpackerrowbytesize = ((tsizet)tilewidth state->bits / planes + 7) / 8 (the tsizet cast keeps the product out of 32-bit arithmetic, so the TILEWIDTH = 2^26+16 case above cannot wrap past the check on 64-bit builds). It reuses that value for the existing TIFFTileSize() sanity check, as decodeStrip() does for strips. After that check and before the realloc, it fails with IMAGINGCODECBROKEN when unpackerrowbytesize > rowbytesize (TIFFTileRowSize()). - decodeAsRGBA() fails with IMAGINGCODECBROKEN when state->bits > 32, because TIFFRGBAImage rows are always 32 bits per pixel. This check runs before TIFFRGBAImageBegin() and any allocation.

With the patch, the tile and RGBA files fail load() with OSError: decoder error -2, the same result the equivalent strip file already gets. The patch also adds a regression test to Tests/testfilelibtiff.py (testunpackerrowwiderthanlibtiffrow). The test embeds the count-2 tile and the duplicated-tag YCbCr strip as base64, following the file's existing convention. The patch was applied to a clean tree and rebuilt: the reproducer no longer triggers, and Tests/testfiletiff.py, Tests/testfilelibtiff.py and Tests/testtiffcrashes.py pass.

These checks close the over-read however the two parsers are made to disagree. Separately, setup() could stop deriving the libtiff rawmode from tags that libtiff will read differently — e.g. treat a PhotometricInterpretation/BitsPerSample/Compression that is not a single well-typed value as "unknown pixel mode", the way ImageWidth/ImageLength are already required to be int at TiffImagePlugin.py:1473, or have ImageFileDirectoryv2.load() keep the first occurrence of a repeated tag as libtiff does (a behaviour change for malformed IFDs that is better made deliberately and separately) — but that only narrows the ways to reach the C-side gap rather than removing it: TiffImagePlugin cannot know how libtiff will resolve every malformed directory, and the decoder-side comparisons are what actually bound the read.

The patch

Reject TIFFs whose unpacker row is wider than libtiff's decoded row in decodeTile() and decodeAsRGBA(), as decodeStrip() already does

Applies to src/libImaging/TiffDecode.c at the commit above.

diff diff --git a/Tests/testfilelibtiff.py b/Tests/testfilelibtiff.py index 3d804ea4a..c08dfe77c 100644 --- a/Tests/testfilelibtiff.py +++ b/Tests/testfilelibtiff.py @@ -1232,6 +1232,50 @@ class TestFileLibTiff(LibTiffTestCase): with pytest.raises(OSError, match="decoder error -9"): im.load() + @pytest.mark.parametrize( + "data", + ( + # 16x16 8-bit greyscale tile, with a PhotometricInterpretation tag that + # has two values. Pillow reads it as YCbCr (rawmode RGBX, 4 bytes/pixel) + # while libtiff ignores it and decodes 1 byte/pixel. + ( + b"SUkqAAgAAAAKAAABBAABAAAAEAAAAAEBBAABAAAAEAAAAAIBAwABAAAACAAA" + b"AAMBAwABAAAACAAAAAYBAwACAAAABgAGABUBAwABAAAAAQAAAEIBBAABAAAA" + b"EAAAAEMBBAABAAAAEAAAAEQBBAABAAAAhgAAAEUBBAABAAAACwEAAAAAAAB4" + b"nAEAAf/+AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUm" + b"JygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJT" + b"VFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+A" + b"gYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6yt" + b"rq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna" + b"29zd3t/g4eLj5OXm5+jp6uvs7e7v8PHy8/T19vf4+foAAQIDBJ9Bepo=" + ), + # 16x16 strip with duplicated BitsPerSample and PhotometricInterpretation + # tags. libtiff keeps the first (8-bit YCbCr, read as 4 bytes/pixel RGBA) + # while Pillow keeps the last (16-bit RGB, rawmode RGB;16N, 6 bytes/pixel). + ( + b"SUkqAAgAAAAMAAABAwABAAAAEAAAAAEBAwABAAAAEAAAAAIBAwADAAAAugEA" + b"AAIBAwADAAAAwAEAAAMBAwABAAAACAAAAAYBAwABAAAABgAAAAYBAwABAAAA" + b"AgAAABEBBAABAAAAngAAABUBAwABAAAAAwAAABYBAwABAAAAEAAAABcBBAAB" + b"AAAAHAEAABICAwACAAAAAQABAAAAAAB4nGNgZGJmYWVj5+Dk4ubh5eMXEBQS" + b"FhEVE5eQlJKWkZWTV1BUUlZRVVPX0NTS1tHV0zcwNDI2MTUzt7C0sraxtbN3" + b"cHRydnF1c/fw9PL28fXzDwgMCg4JDQuPiIyKjomNi09ITEpOSU1Lz8jMys7J" + b"zcsvKCwqLiktK6+orKquqa2rb2hsam5pbWvv6Ozq7unt658wcdLkKVOnTZ8x" + b"c9bsOXPnzV+wcNHiJUuXLV+xctXqNWvXrd+wcdPmLVu3bd+xc9fuPXv37T9w" + b"8NDhI0ePHT9x8tTpM2fPnb9w8dLlK1evXb9x89btO3fv3X/w8NHjJ0+fPX/x" + b"8tXrN2/fvf/w8dPnL1+/ff/x89fvP3///WcY9f+I9j8AoGJ+kAgACAAIABAA" + b"EAAQAA==" + ), + ), + ) + @pytest.mark.filterwarnings("ignore:Metadata Warning") + def testunpackerrowwiderthanlibtiffrow(self, data: bytes) -> None: + # The unpacker chosen by Pillow reads more bytes per row than libtiff + # decoded, so the decoder must reject the image rather than read past + # the end of its buffer + with Image.open(io.BytesIO(base64.b64decode(data))) as im: + with pytest.raises(OSError, match="decoder error -2"): + im.load() + @pytest.mark.parametrize("compression", ("tiffadobedeflate", "jpeg")) def testsavemultistrip(self, compression: str, tmppath: Path) -> None: im = hopper("RGB").resize((256, 256)) diff --git a/src/libImaging/TiffDecode.c b/src/libImaging/TiffDecode.c index 8a57c523d..2ee6c5f0a 100644 --- a/src/libImaging/TiffDecode.c +++ b/src/libImaging/TiffDecode.c @@ -304,6 +304,15 @@ decodeAsRGBA(Imaging im, ImagingCodecState state, TIFF tiff) { TRACE(("RowsPerBlock: %u \n", rowsperblock)); + // TiffRGBAImages are 32bits/pixel. If the unpacker reads more bits per pixel + // than that, (at least) the last row of the block will have a read buffer + // overflow. + if (state->bits > 32) { + TRACE(("Decode Error, unpacker bits %d > 32\n", state->bits)); + state->errcode = IMAGINGCODECBROKEN; + return -1; + } + if (!(TIFFRGBAImageOK(tiff, emsg) && TIFFRGBAImageBegin(&img, tiff, 0, emsg))) { TRACE(("Decode error, msg: %s", emsg)); state->errcode = IMAGINGCODECBROKEN; @@ -397,7 +406,7 @@ decodeTile( ) { INT32 x, y, tiley, currenttilelength, currenttilewidth; UINT32 tilewidth, tilelength; - tsizet tilebytessize, rowbytesize; + tsizet tilebytessize, rowbytesize, unpackerrowbytesize; UINT8 newdata; tilebytessize = TIFFTileSize(tiff); @@ -431,7 +440,8 @@ decodeTile( return -1; } - if (tilebytessize > ((tilelength state->bits / planes + 7) / 8) tilewidth) { + unpackerrowbytesize = ((tsizet)tilewidth state->bits / planes + 7) / 8; + if (tilebytessize > (unpackerrowbytesize tilelength)) { // If the tile size as expected by LibTiff isn't what we're expecting, abort. // man: TIFFTileSize returns the equivalent size for a tile of data as it // would be returned in a call to TIFFReadTile ... @@ -439,6 +449,13 @@ decodeTile( return -1; } + // if the unpacker calculated row size is > row byte size, (at least) the last + // row of the tile will have a read buffer overflow. + if (unpackerrowbytesize > rowbytesize) { + state->errcode = IMAGINGCODECBROKEN; + return -1; + } + state->bytes = tilebytessize; TRACE(("TIFFTileSize: %d\n", state->bytes));

The reproducer

<details> <summary>Reproducer — <code>repro</code>, 4,178 bytes (click to open)</summary>

Its last line is BUG when the issue triggers and OK when it does not. Re-run on a clean build of that commit it printed BUG.

python #!/usr/bin/env python3 Heap over-read in decodeTile()/decodeAsRGBA() (src/libImaging/TiffDecode.c), stock build, no sanitizer needed. Pillow picks the row unpacker from its own IFD parse, libtiff sizes the decode buffer from its parse; when they disagree the unpacker reads past state->buffer and the bytes land in the image. Evidence: (1) pixels of a fully-defined 16x16 file change with glibc's MALLOCPERTURB fill byte (heap bytes beyond the buffer became pixels); (2) a 65536x16 tile SIGSEGVs in copy4 <- decodeTile. Runs in a few seconds. import os, shutil, struct, subprocess, sys, tempfile, zlib

W = tempfile.mkdtemp(); S, L = 3, 4

def tiff(entries, data): # little-endian classic TIFF, one IFD, tags in given order dataoff = 8 + 2 + 12 len(entries) + 4; extraoff = dataoff + len(data) ifd, extra = struct.pack("<H", len(entries)), b"" for tag, typ, vals in entries: if vals is None: typ, vals = L, [dataoff] raw = b"".join(struct.pack("<H" if typ == S else "<L", v) for v in vals) if len(raw) > 4: raw, extra = struct.pack("<L", extraoff + len(extra)), extra + raw ifd += struct.pack("<HHL", tag, typ, len(vals)) + raw.ljust(4, b"\0") return b"II\0" + struct.pack("<L", 8) + ifd + b"\0" 4 + data + extra

def tile(w, h, spp, photo): # one deflate tile, 8 bit/sample d = zlib.compress(bytes(i % 251 for i in range(w h spp))) return tiff([(256, L, [w]), (257, L, [h]), (258, S, [8] spp), (259, S, [8])] + photo + [(277, S, [spp]), (322, L, [w]), (323, L, [h]), (324, L, None), (325, L, [len(d)])], d)

d = zlib.compress(bytes(range(256)) 3) files = { # Photometric count 2 (6,6): libtiff ignores tag -> 1 B/px; Pillow keeps 6 -> RGBX copy4 4 B/px (HEAD only) "tilecount2.tif": tile(16, 16, 1, [(262, S, [6, 6])]), # Photometric duplicated 2 then 6, 3 samples: libtiff RGB 3 B/px; Pillow RGBX 4 B/px (also released versions) "tiledup.tif": tile(16, 16, 3, [(262, S, [2]), (262, S, [6])]), # strip, libtiff sees 8-bit YCbCr -> decodeAsRGBA 4 B/px; Pillow sees RGB;16 -> 6 B/px "ycbcrdup.tif": tiff([(256, S, [16]), (257, S, [16]), (258, S, [8, 8, 8]), (258, S, [16, 16, 16]), (259, S, [8]), (262, S, [6]), (262, S, [2]), (273, L, None), (277, S, [3]), (278, S, [16]), (279, L, [len(d)]), (530, S, [1, 1])], d), "tilebig.tif": tile(65536, 16, 1, [(262, S, [6, 6])]), } for n, b in files.items(): open(f"{W}/{n}", "wb").write(b)

LOAD = r""" import sys, warnings; warnings.simplefilter("ignore") from PIL import Image im = Image.open(sys.argv[1]); print(Image.core.file, im.mode, im.size, im.tile[0].args[0], file=sys.stderr) im.load(); sys.stdout.write(im.tobytes().hex()) """ def run(name, perturb): p = subprocess.run([sys.executable, "-c", LOAD, f"{W}/{name}"], captureoutput=True, text=True, env=dict(os.environ, MALLOCPERTURB=str(perturb))) return p.returncode, p.stdout, p.stderr.strip().splitlines()[-1:] or [""]

leak = False for n in ("tilecount2.tif", "tiledup.tif", "ycbcrdup.tif"): r1, a, info = run(n, 85); r2, b, = run(n, 170) print(f"== {n}: {info[0]} rc={r1},{r2}") if r1 == 0 and r2 == 0 and a != b: i = next(k for k in range(0, len(a), 2) if a[k:k+2] != b[k:k+2]) print(f" pixel bytes depend on malloc fill pattern from byte {i//2} of {len(a)//2}:") print(f" PERTURB=85 : ...{a[i-8:i+40]}\n PERTURB=170: ...{b[i-8:i+40]}") leak = True else: print(" identical output / error -> no leak observed")

rc, , info = run("tilebig.tif", 0) print(f"== tilebig.tif: {info[0]} rc={rc}" + (" (SIGSEGV)" if rc == -11 else "")) crash = rc == -11 if crash and shutil.which("gdb"): bt = subprocess.run(["gdb", "-batch", "-ex", "run", "-ex", "bt 4", "--args", sys.executable, "-c", LOAD, f"{W}/tilebig.tif"], captureoutput=True, text=True).stdout print("\n".join(l for l in bt.splitlines() if l.startswith("#"))) shutil.rmtree(W) print(f"summary: heap bytes in pixels={leak} stock SIGSEGV={crash}") print("BUG" if leak or crash else "OK") </details>

---