An integer truncation flaw leading to a heap-based buffer overflow was found in ImageMagick in pict.c. Detailed stacktrace with reproducer can be found here: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1448803 Upstream patch for the pict.c problem is a subsection (the pict.c part) of the following commit: https://github.com/ImageMagick/ImageMagick/commit/0f6fc2d5bf8f500820c3dbcf0d23ee14f2d9f734 CVE request: http://seclists.org/oss-sec/2015/q4/45
Created ImageMagick tracking bugs for this issue: Affects: fedora-all [bug 1269567]
Upstream patch for the pict.c problem is a subsection (the pict.c part) of the following commit: https://github.com/ImageMagick/ImageMagick/commit/0f6fc2d5bf8f500820c3dbcf0d23ee14f2d9f734 When calculating the amount of bytes per row, the result is truncated down to unsigned short. > row_bytes=(unsigned short) (image->columns | 0x8000); or > row_bytes=(unsigned short) ((4*image->columns) | 0x8000); This truncated value is later used to allocate the scanline memory (if image->columns is big, the resulting row_bytes value may turn out to be too small): > scanline=(unsigned char *) AcquireQuantumMemory(row_bytes,sizeof(*scanline)); Finally, we calculate pointers into the scanline buffer via: > red=scanline; > green=scanline+image->columns; > blue=scanline+2*image->columns; > opacity=scanline+3*image->columns; Notice that when calculating e.g. "blue", the original, non-truncated image->columns value is taken, possibly leading to out-of-bounds writes when trying to write pixels into the scanline buffer.
The TGA flaw (CVE-2015-8894) has been moved to: https://bugzilla.redhat.com/show_bug.cgi?id=1347275
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Via RHSA-2016:1237 https://access.redhat.com/errata/RHSA-2016:1237