ImageMagick 7.0.6-1

ReadGIFImage in coders/gif.c in ImageMagick 7.0.6-1 and GraphicsMagick 1.3.26 leaves the palette uninitialized when processing a GIF file that has neither a global nor local palette. If the affected product is used as a library loaded into a process that operates on interesting data, this data sometimes can be leaked via the uninitialized palette.

Published: 2017-10-12T08:00:00.000Z
Updated: 2024-08-05T19:50:16.492Z

In coders/xbm.c in ImageMagick 7.0.6-1 Q16, a DoS in ReadXBMImage() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted XBM file, which claims large rows and columns fields in the header but does not contain sufficient backing data, is provided, the loop over the rows would consume huge CPU resources, since there is no EOF check inside the loop.

Published: 2017-09-07T06:00:00.000Z
Updated: 2024-08-05T19:20:40.989Z

In ImageMagick before 6.9.9-3 and 7.x before 7.0.6-3, there is a missing NULL check in the ReadMATImage function in coders/mat.c, leading to a denial of service (assertion failure and application exit) in the DestroyImageInfo function in MagickCore/image.c.

Published: 2017-08-24T06:00:00.000Z
Updated: 2024-08-05T19:05:19.142Z

In ImageMagick before 6.9.9-4 and 7.x before 7.0.6-4, a crafted file could trigger a memory leak in ReadOnePNGImage in coders/png.c.

Published: 2017-08-23T06:00:00.000Z
Updated: 2024-08-05T18:58:12.331Z

In ImageMagick before 6.9.9-1 and 7.x before 7.0.6-2, the ReadOnePNGImage function in coders/png.c allows remote attackers to cause a denial of service (application hang in LockSemaphoreInfo) via a PNG file with a width equal to MAGICK_WIDTH_LIMIT.

Published: 2017-08-23T06:00:00.000Z
Updated: 2024-08-05T18:58:12.286Z