GHSA-6r8x-57c9-28j4 Pillow: Heap out-of-bounds write `Image.paste()` / `Image.crop()` via signed coordinate overflow
SummaryPillow'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:The same root cause is also reachable through `Image.crop()` and
`Image.alpha_composite()`. No private API, ctypes, custom Python object, or
malformed image file is needed.This has been confirmed as an ASAN heap-buffer-overflow write. On normal
non-ASAN Pillow builds, the minimal trigger corrupts the heap and aborts with
`double free or corruption (out)`Details`src/PIL/Image.py:paste()` accepts a 4-tuple box and passes it to the native
`ImagingCore.paste()` method:`src/_imaging.c:_paste()` parses the four Python coordinates into signed `int`
values and calls `ImagingPaste()`:`src/libImaging/Paste.c:ImagingPaste()` computes and clips the region using
signed `int` arithmetic: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`: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:Examples for `RGBA`: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:`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()`.PoCThe following standalone script exercises all three public API paths. Save it
as `b021_poc.py` and run it with `paste`, `crop`, or `alpha`.Run against an ASAN build:Observed ASAN signature for the direct `Image.paste()` path:On non-ASAN Pillow `12.2.0` and local `12.3.0.dev0`, the direct minimal
`Image.paste()` trigger returns from `paste()` and then the process aborts
during cleanup with:Observed ASAN signature for the `Image.crop()` and `Image.alpha_composite()`
paths:Suggested fixAvoid signed overflow in paste/crop coordinate arithmetic. Use checked
arithmetic or a wider type before calculating widths and clipped endpoints.For example, reject boxes whose endpoint subtraction cannot be represented
cleanly, and clip using non-overflowing comparisons:`ImagingCrop()` should receive the same treatment for `sx1 - sx0`,
`dx0 = -sx0`, and `dx1 = imIn->xsize - sx0`.ImpactThis 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.
CVSS v3.1 score: 7.5