GHSA-6r8x-57c9-28j4 Pillow: Heap out-of-bounds write `Image.paste()` / `Image.crop()` via signed coordinate overflow

• PyPI Pillow: < 12.3.0 → fixed in 12.3.0

Summary Pillow's public image coordinate APIs can trigger a native heap out-of-bounds write when given coordinates near the signed 32-bit integer limits. In 4-byte pixel modes such as `RGBA`, this becomes a controlled backward heap underwrite: for a source image of width `W`, Pillow writes `4 * W` attacker-controlled bytes starting `4 * W` bytes before the destination row pointer. With successful large image allocation, the theoretical upper bound is ~2 GiB backwards from the destination row. Minimal public API trigger: ```python from PIL import Image INT_MIN = -(1 image, PyImaging_AsImaging(source), ..., x0, y0, x1, y1); ``` `src/libImaging/Paste.c:ImagingPaste()` computes and clips the region using signed `int` arithmetic: ```c xsize = dx1 - dx0; ysize = dy1 - dy0; if (dx0 + xsize > imOut->xsize) { xsize = imOut->xsize - dx0; } ``` With `dx0 = 2147483646` and `dx1 = -2147483648`, `dx1 - dx0` wraps to `2`. That matches the 2-pixel source image, so the size check passes. The later `dx0 + xsize` clip check wraps around and does not reject the out-of-bounds destination. For 4-byte pixel modes such as `RGBA`, the paste loop then multiplies `dx` by `pixelsize`: ```c dx *= pixelsize; xsize *= pixelsize; memcpy(imOut->image[y + dy] + dx, imIn->image[y + sy] + sx, xsize); ``` For the minimal PoC, this writes 8 attacker-controlled bytes 8 bytes before the destination row allocation. The primitive scales with the attacker-controlled source width: ```text source width = W box = ((1 writes 8 bytes before the row W = 1024 -> writes 4096 bytes before the row W = 65536 -> writes 256 KiB before the row W = 1000000 -> writes about 4 MiB before the row ``` Pillow's image creation guard currently limits `xsize` to roughly `INT_MAX / 4 - 1`, so the theoretical upper bound for this `RGBA` underwrite is `2,147,483,640` bytes before the destination row pointer. In practice, the usable range depends on memory availability, allocator layout, and process heap state. Two other documented APIs reach the same sink: ```python Image.crop() path left = INT_MIN + 2 Image.new("RGBA", (2, 1)).crop((left, 0, left + 2, 1)) Image.alpha_composite() path, via its internal crop() base = Image.new("RGBA", (2, 1)) over = Image.new("RGBA", (2, 1), (0x41, 0x42, 0x43, 0x44)) base.alpha_composite(over, dest=(left, 0)) ``` `Image.crop()` keeps `right - left` small, so the Python decompression-bomb check allows it. `src/libImaging/Crop.c` then computes wrapped paste coordinates and calls `ImagingPaste()`. PoC The following standalone script exercises all three public API paths. Save it as `b021_poc.py` and run it with `paste`, `crop`, or `alpha`. ```python !/usr/bin/env python3 import argparse import sys from PIL import Image INT_MIN = -(1 INT_MAX || ysize64 > INT_MAX) { return ImagingError_ValueError("bad box"); } ``` `ImagingCrop()` should receive the same treatment for `sx1 - sx0`, `dx0 = -sx0`, and `dx1 = imIn->xsize - sx0`. Impact This is a heap out-of-bounds write in Pillow's native C extension, reachable through documented public image APIs. Applications are impacted if an untrusted user can control image operation coordinates passed to Pillow, for example crop boxes, paste boxes, or overlay positions. The bytes written in the direct `Image.paste()` variant are copied from the source image, so attacker-controlled source pixels can influence the out-of-bounds write. For `RGBA`, the write is a backward heap underwrite whose offset and length are both `4 * source_width`, bounded in practice by successful image allocation and heap layout.