magick/configure.c | 8 4 + 4 - 0 !
1 file changed, 4 insertions(+), 4 deletions(-)

 [patch] 
 directory for  the "installed" version of ImageMagick. 
 Patch pulled from upstream svn 
 https://www.imagemagick.org/subversion/ImageMagick/trunk 

magick/property.c | 116 71 + 45 - 0 !
1 file changed, 71 insertions(+), 45 deletions(-)

 [patch] imagemagick invalid validation and denial of service

This patch fix two security bug
*    [CVE-2012-0247] When parsing a maliciously crafted image with incorrect offset and count in the ResolutionUnit tag in EXIF IFD0, ImageMagick copies two bytes into an invalid address.
*    [CVE-2012-0248] When parsing a maliciously crafted image with an IFD whose all IOP tags' value offsets point to the beginning of the IFD itself. As a result, ImageMagick parses the IFD structure indefinitely, causing a denial of service.

Thanks goes to the Mr Joonas Kuorilehto & Mr Aleksis Kauppinen from Codenomicon CROSS project for discovering the vulnerabilities and providing a test case file.
Also to the Finnish Communications Regulatory Authority (CERT-FI) for alerting us to these vulnerabilities.

(cherry picked from commit cb8dd0b021332238efa17bf88877723c8a960964)

magick/profile.c | 15 13 + 2 - 0 !
magick/property.c | 2 2 + 0 - 0 !
2 files changed, 15 insertions(+), 2 deletions(-)

 [patch] fix cve-2012-1185 / cve-2012-1186 assignment notification

The original fixes for the ImageMagick issues CVE-2012-0247 and
CVE-2012-0248 are incomplete.

The original fix for CVE-2012-0247 failed to check for the possibility
of an integer overflow when computing the sum of "number_bytes" and
"offset". This resulted in a wrap around into a value smaller than
"length", making original CVE-2012-0247 introduced "length" check still
to be possible to bypass, leading to memory corruption.

This was backported from svn revision 6998 aka git
28b3ba177e797d2b9a0ac0b44de187264e99493e

coders/jpeg.c | 8 7 + 1 - 0 !
coders/tiff.c | 7 4 + 3 - 0 !
magick/property.c | 4 4 + 0 - 0 !
3 files changed, 15 insertions(+), 4 deletions(-)

 [patch] fix security holes jpeg/exif/tiff

An out-of heap-based buffer read flaw was found in the way ImageMagick,
retrieved Exchangeable image file format (Exif) header tag information
from certain JPEG files.

A remote attacker could provide a JPEG image file, with EXIF header
containing specially-crafted tag values, which once opened in some ImageMagick
tool would lead to the crash of that tool (denial of service).

Fix:
* [CVE-2012-0259] JPEG EXIF tag crash.
* [CVE-2012-0260] Excessive memory use with JPEG restart markers.
* [CVE-2012-1798] Copying of invalid memory when reading TIFF EXIF IFD.

magick/profile.c | 7 5 + 2 - 0 !
magick/property.c | 4 2 + 2 - 0 !
2 files changed, 7 insertions(+), 4 deletions(-)

 [patch] fix security bug for special crafted exif properties

The original patch for CVE-2012-0259 turned out to be insufficient.

The problem is an integer overflow error in the "GetEXIFProperty()"
function (magick/property.c, around line 1288):

number_bytes=(size_t) components*tag_bytes[format];

When processing EXIF directory entries with tags of e.g. format 5
EXIF_FMT_URATIONAL) and a large components count, the calculation can
overflow and e.g. lead to "number_bytes" being 0. If that's the case,
subsequent checks can be bypassed, resulting in the loop in the
"EXIFMultipleFractions" macro to iterate through a large number of
"components". This leads to out-of-bound reads until eventually causing
a segmentation fault when trying to read beyond the limits of heap memory.

CVE-2012-1610 has been assigned to this issue.

Note: The initial patch for this issue is still necessary to prevent
access of uninitialized/incorrect memory when e.g. processing specially
crafted EXIF tags with a component count of 0.

coders/psd.c | 8 4 + 4 - 0 !
1 file changed, 4 insertions(+), 4 deletions(-)

 cve-2014-1947: fix buffer overrun

magick/locale.c | 10 9 + 1 - 0 !
1 file changed, 9 insertions(+), 1 deletion(-)

 [patch] prevent buffer overflow in messaging system

NOTE: Upstream commit references this as CVE-2014-1947. But CVE-2014-1947 is
the CVE assigned for the issue fixed by
http://trac.imagemagick.org/changeset/13736