Read from tall PSD tiles safely

[Kesavamoorthig06]

Issue

When opening a PackBits-compressed PSD, PsdImagePlugin._maketile reads the per-row bytecounts table using a size taken straight from the file header:

bytecount = read(channels * ysize * 2)

ysize is the declared image height, an unsigned 32-bit field that is never validated. A 40-byte PSD declaring a height of 0xFFFFFFFF makes Pillow ask read() for ~26 GB while parsing the header. Where the allocation is refused, Image.open() dies with a raw MemoryError; where it succeeds, the process still pins tens of gigabytes of address space for a file containing no image data. Any service that opens untrusted PSDs can be taken down by a single tiny upload.

Both the merged image (read during Image.open()) and individual layers (read through .layers) go through _maketile, so both paths are affected.

Reproduction

import struct
from PIL import Image

hdr = b"8BPS" + struct.pack(">H", 1) + b"\x00" * 6
hdr += struct.pack(">HIIHH", 3, 0xFFFFFFFF, 1, 8, 3)  # 4-billion-row RGB image
hdr += struct.pack(">IIIH", 0, 0, 0, 1)  # empty sections, PackBits compression

with open("crash.psd", "wb") as f:
    f.write(hdr)  # 40 bytes total

Image.open("crash.psd")  # MemoryError

Fix

Read the table with ImageFile._safe_read(), which exists for exactly this case ("Unlike fp.read(n), this function doesn't trust the user"). It reads block by block instead of pre-allocating the declared size, and raises OSError("Truncated File Read") when the file cannot supply the table:

OSError: Truncated File Read

One subtlety: _safe_read returns b"" for a non-positive size, but read() raises ValueError there, and test_bounds_crash_overflow relies on a crafted layer with a negative height being rejected with ValueError. The fix rejects a negative height explicitly first, preserving that behavior.

The regression test opens a 40-byte PSD declaring a 0xFFFFFFFF-tall image and asserts it is rejected with OSError. Without the fix, the test dies with MemoryError.

[radarhere]

I suspect this problem was only introduced in #10089

[Kesavamoorthig06]

Ah interesting - I went back and tried the file on d401c61^, just before #10089, and it still hits the same MemoryError. This comes through _open() -> _maketile(self.fp, ...) for the merged image, rather than the layers code changed in that PR. I also found that read in 6.2.0, 7.2.0, 8.4.0 and 9.5.0, so it looks like it's been around for a while.