The problem is in the function xcf_load_vector() in app/xcf/xcf-load.c
of the source tree. For each "stroke" being read, the code reads an
uint32 from the XCF file into the variable num_axes, and then for each
control proint of the stroke reads num_axes floats from the file into
the stack-allocated array coords whose size is hard-coded as 6.

A malicious XCF file creater could write a large number into the
num_axes position and trick the XCF reader into overwriting part of
the stack with raw data read from the file. On little-endian systems,
the function xcf_read_float() that actually reads the floats does a
byte-order conversion on the data it reads but does not do any special
float processing, so an attacker has direct control of the data
written to the stack.

I have not attempted to construct an working exploit (though I did
verify being able to crash Gimp with a naively patched image file),
but there seems to be no reason why the overrun could not be used to
mount a standard arbitrary code execution attack if one can get the
victim to try to load an appropriately crafted image file.

The attack is in the VECTORS property of an XCF file which pure XCF
_viewers_ (e.g. imagemagick or xcftools) normally skip without
parsing.  Thus an attack file can easily be written such that the
image will display correctly with no symptoms at all in a viewer
application.

The same bug appears in the current CVS head.