A buffer overflow vulnerability has been fixed by following commit:

https://github.com/ImageMagick/ImageMagick/commit/76401e172ea3a55182be2b8e2aca4d07270f6da6

Related CVE request: http://www.openwall.com/lists/oss-security/2016/08/02/6

control: fixed -1 8:6.8.9.9-7.2

according to http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=30259&p=136359#p136359
it is not for us

This is a ImageMagick 7 specific patch. We allocate the buffers based
on the number of image pixel channels, however, the method was not
returning the correct number of channels, 3 (RGB) instead of 4 (RGBA).
Calling SyncImagePixelCache() forces an update to the pixel cache
morphology and then GetImageChannels() correctly returns 4 channels. A
better fix, which we subsequently added, was to ensure that each
image, as it is returned by a coder, is synced such that
GetImageChannels() always returns the correct value. For this
particular case, we set the image trait to alpha but we did not
evaluate the image to update the change in the pixel cache morphology
from 3 to 4.

control: fixed -1 8:6.8.9.9-7.2

according to http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=30259&p=136359#p136359
it is not for us

This is a ImageMagick 7 specific patch. We allocate the buffers based
on the number of image pixel channels, however, the method was not
returning the correct number of channels, 3 (RGB) instead of 4 (RGBA).
Calling SyncImagePixelCache() forces an update to the pixel cache
morphology and then GetImageChannels() correctly returns 4 channels. A
better fix, which we subsequently added, was to ensure that each
image, as it is returned by a coder, is synced such that
GetImageChannels() always returns the correct value. For this
particular case, we set the image trait to alpha but we did not
evaluate the image to update the change in the pixel cache morphology
from 3 to 4.

close 833485 7.0.2.7
thanks