GIMP ships a plug-in (file-pvr) that loads textures stored in the PowerVR
(.pvr) texture format.  Inside pvr_decode_compressed (the helper used for
the four compressed-VQ data formats), the size of the destination pixel buffer
is computed in 32-bit int arithmetic from the file's declared width,
height, and a derived component count.  For attacker-chosen 16-bit dimension
pairs (e.g. width = 32 768, height = 32 769) and an alpha-bearing pixel
mode (MODE_ARGB1555 or MODE_ARGB4444), the product
width × height × n_components overflows INT_MAX and wraps to a small
positive value — 131 072 bytes for the demonstrated trigger.  The function
allocates that much memory and then writes into it using the original (large)
width × n_components row stride, producing a heap-based buffer overflow
write at the very first row past the allocated boundary.
The dispatcher in load_image does perform a bounds check
(mipmap_width >= MAX_TWIDDLE_SIZE and mipmap_height >= MAX_TWIDDLE_SIZE),
but for data_format == MODE_COMPRESSED_MIPMAP (or MODE_SMALL_VQ_MIPMAP)
that check applies only to the auto-derived mipmap dimensions, not to the
file's width/height values that are passed unchecked into
pvr_decode_compressed.  This is the gap that makes the integer overflow
reachable.
Triggering the vulnerability requires only that the user open or thumbnail a
crafted .pvr file in GIMP — for example by double-clicking the file,
dragging it into GIMP, or via any indexer that invokes GIMP's file-thumbnailer
backend.
The bug is a heap write (CWE-787) of attacker-influenced bytes off the
end of an undersized buffer; the writes are short (1 byte at a time per
component) but their starting offset and surrounding contents are derived
from data that the attacker fully controls (the codebook bytes in the
PVR file).  This makes the bug a strong candidate for heap corruption /
arbitrary write primitive that may be developed into remote code execution.
At minimum it provides reliable denial-of-service via plug-in crash.