CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
GraphicsMagick 1.3.26 is vulnerable to a memory information disclosure vulnerability found in the DescribeImage function of the magick/describe.c file, because of a heap-based buffer over-read. The portion of the code containing the vulnerability is responsible for printing the IPTC Profile information contained in the image. This vulnerability can be triggered with a specially crafted MIFF file. There is an out-of-bounds buffer dereference because certain increments are never checked. |
In GraphicsMagick 1.3.26, a memory leak vulnerability was found in the function ReadMATImage in coders/mat.c. |
GraphicsMagick 1.3.26 has a heap overflow in the WriteRGBImage() function in coders/rgb.c when processing multiple frames that have non-identical widths. |
There are lots of memory leaks in the GMCommand function in magick/command.c in GraphicsMagick 1.3.26 that will lead to a remote denial of service attack. |
There is an invalid free in the MagickFree function in magick/memory.c in GraphicsMagick 1.3.26 that will lead to a remote denial of service attack. |
GraphicsMagick 1.3.26 has a denial of service issue in ReadXBMImage() in a coders/xbm.c "Read hex image data" version!=10 case that results in the reader not returning; it would cause large amounts of CPU and memory consumption although the crafted file itself does not request it. |
GraphicsMagick 1.3.26 has a segmentation violation in the WriteMAPImage() function in coders/map.c when processing a non-colormapped image, a different vulnerability than CVE-2017-11642. |
A memory allocation failure was discovered in the ReadPNMImage function in coders/pnm.c in GraphicsMagick 1.3.26. The vulnerability causes a big memory allocation, which may lead to remote denial of service in the MagickRealloc function in magick/memory.c. |
The ReadJNGImage and ReadOneJNGImage functions in coders/png.c in GraphicsMagick 1.3.26 do not properly manage image pointers after certain error conditions, which allows remote attackers to conduct use-after-free attacks via a crafted file, related to a ReadMNGImage out-of-order CloseBlob call. NOTE: this vulnerability exists because of an incomplete fix for CVE-2017-11403. |
The ReadSUNImage function in coders/sun.c in GraphicsMagick 1.3.26 has an issue where memory allocation is excessive because it depends only on a length field in a header. This may lead to remote denial of service in the MagickMalloc function in magick/memory.c. |
The ReadSUNImage function in coders/sun.c in GraphicsMagick 1.3.26 has a colormap heap-based buffer over-read. |
In GraphicsMagick 1.3.26, an allocation failure vulnerability was found in the function ReadMNGImage in coders/png.c when a small MNG file has a MEND chunk with a large length value. |
In ReadOneJNGImage in coders/png.c in GraphicsMagick 1.3.26, a Null Pointer Dereference occurs while transferring JPEG scanlines, related to a PixelPacket pointer. |
GraphicsMagick 1.3.26 has a NULL pointer dereference in the WritePCLImage() function in coders/pcl.c during writes of monochrome images. |
GraphicsMagick 1.3.26 has a Memory Leak in the PersistCache function in magick/pixel_cache.c during writing of Magick Persistent Cache (MPC) files. |
GraphicsMagick 1.3.26 has a NULL pointer dereference in the WriteMAPImage() function in coders/map.c when processing a non-colormapped image, a different vulnerability than CVE-2017-11638. |
GraphicsMagick 1.3.26 has double free vulnerabilities in the ReadOneJNGImage() function in coders/png.c. |
The ReadJPEGImage function in coders/jpeg.c in GraphicsMagick 1.3.26 creates a pixel cache before a successful read of a scanline, which allows remote attackers to cause a denial of service (resource consumption) via crafted JPEG files. |
When GraphicsMagick 1.3.25 processes a DPX image (with metadata indicating a large width) in coders/dpx.c, a denial of service (OOM) can occur in ReadDPXImage(). |
When GraphicsMagick 1.3.25 processes a MATLAB image in coders/mat.c, it can lead to a denial of service (OOM) in ReadMATImage() if the size specified for a MAT Object is larger than the actual amount of data. |