Activity for Bob Friesenhahn
-
Bob Friesenhahn posted a comment on ticket #465
This issue is also fixed by Mercurial changeset 15170:fb09ca6dd22c. Thank you for the report.
-
NULL Pointer Dereference triggered by malformed file
-
This issue is fixed by Mercurial changeset 15170:fb09ca6dd22c. Thank you very much for the report.
-
NULL Pointer Dereference from Malformed Input File
-
Please provide the GraphicsMagick release version you are using as well as the JPEG file you tested with wrapped up in a zip or tar.gz file in order to avoid SourceForge re-writing the file. If you do not provide this information, your report will be closed as invalid due to not including basic information which should be included with any bug report. Use of EXIF orientation in rotations was not introduced until GM 1.3.18 but improvements/fixes to this feature did appear in 1.3.26.. Preservation...
-
NULL Pointer Dereference from Malformed Input File
-
NULL Pointer Dereference triggered by malformed file
-
On Wed, 13 Sep 2017, Glenn Randers-Pehrson wrote: Fixed in coders/png.c, but wouldn't it make more sense to have MagickAllocateMemory check against MemoryResource? The memory resource you are now checking is a totalized value which means that one is supposed to allocate from it, and then deallocate from it. It is not a limit on any one allocation. This means that without geat care this is another form of leak. In general we have no control over how a user (or library) allocates and deallocates memory...
-
allocation failure in ReadTIFFImage
-
allocation failure in ReadTIFFImage
-
allocation failure in ReadTIFFImage
-
allocation failure in ReadOnePNGImage
-
allocation failure in ReadTIFFImage
-
allocation failure in ReadOnePNGImage
-
Heap out of bounds read in ReadRLEImage()
-
Heap out of bounds read in DrawDashPolygon()
-
Heap out of bounds read in DrawDashPolygon()
-
This problem is fixed by Mercurial changeset 15163:2835184bfb78. Thanks for reporting the issue.
-
This problem is already fixed by Mercurial Changeset 15162:7ccf29bc782e. The problem was first reported to us via email from 'LCatro' on 18 Jul 2017.
-
Heap buffer overflow in uil.c
-
Heap buffer overflow in AcquireCacheNexus()
-
I am able to reproduce this.
-
Null pointer dereference in InsertRow()
-
Null pointer dereference in InsertRow()
-
Fixed by Mercurial changeset 15161:3dc7b4e3779d.
-
assertion failure in magick/pixel_cache.c:1089
-
assertion failure in magick/pixel_cache.c:1089
-
This one was fixed by Mercurial changeset 15141:358608a46f0a on August 29th.
-
On Fri, 8 Sep 2017, thib_rdr wrote: Both images are supposed to contain the red arrow. As I said, the images came from uploads from iOS and Windows devices. Regarding my installation of Graphics Magick, it's the version available in the Jessie repository from Debian. What is the full ouput from 'gm -version'? It is likely that Debian Jessie is using some version of TurboJPEG. Bob
-
On Fri, 8 Sep 2017, thib_rdr wrote: Hi, and thanks for your answer. The 01ac9fe3-0737-45c1-9996-d2ed6d152fff.jpg is the result of the conversion. The image containing a red arrow is the original or are both of the images supposed to contain the red arrow? Regarding the rest of your answer, I'm not sure where you are getting at. Could you elaborate a bit ? There is something severely wrong if you can't write a proper JPEG file using GM. I would tend to suspect the JPEG library you are using or a mismatch...
-
On Fri, 8 Sep 2017, troudier wrote: I'm running a resize image server, basically where our users can upload photos from client mobile apps, and graphicsmagicks is in charge of generating 3 images from the source image (we generate one of 300px, one of 1024px, one of 2048px) to be used in various places in a webapp afterwards. We started the resize server approximately two months ago, and some users recently reported some problems with their images. Basically, some images were blurry, with lots of...
-
Testing shows that Mercurial changeset 15138:98721124e51f resolves this problem.
-
heap use after free in CloseBlob
-
use-after-free in CloseBlob (blob.c) (INCOMPLETE FIX FOR CVE-2017-11403)
-
This problem appears to be resolved by Mercurial changeset 15138:98721124e51f as per my own testing.
-
allocation failure in ReadMNGImage
-
I am not seeing any large memory usage with the test case after Glenn's fix.
-
memory allocation failure in MagickRealloc
-
Fixed by Mercurial changeset 15130:3bbf7a13643d. Thank you for reporting this problem.
-
Problem is fixed by the combination of changesets 15122:b6c54b2d5991, 15123:f87246749079, 15125:91b707030bda, 15127:3e3ef99689df, and 15128:3dd7bf268680. Thank you for reporting the problem and providing a test case.
-
memory leak in ReadMATImage
-
memory leak in ReadMATImage
-
PBM decoder issue: 14:50:15 0:01 0.000u 18681 constitute.c/ReadImage/1601/Coder: Invoking "PBM" decoder (Portable bitmap format (black/white)) subimage=0 subrange=0 14:50:15 0:01 0.000u 18681 pnm.c/ReadPNMImage/318/Coder: PNM Format Id: P1 14:50:15 0:01 0.000u 18681 pnm.c/ReadPNMImage/531/Coder: Dimensions: 99999999x16 14:50:15 0:01 0.000u 18681 pnm.c/ReadPNMImage/536/Coder: Max Value: 1 14:50:15 0:01 0.000u 18681 pnm.c/ReadPNMImage/553/Coder: Image Depth: 1 14:50:15 0:01 0.000u 18681 pnm.c/ReadPNMImage/555/Coder:...
-
memory allocation failure in MagickRealloc
-
use-after-free in CloseBlob (blob.c) (INCOMPLETE FIX FOR CVE-2017-11403)
-
This is a problem with the MNG decoder. It appears that it will always crash if an exception was thrown (similar to observed with JNG). I hope that Glenn will fix it. 14:44:59 0:01 0.000u 18511 constitute.c/ReadImage/1601/Coder: Invoking "MNG" decoder (Multiple-image Network Graphics) subimage=0 subrange=0 14:44:59 0:01 0.000u 18511 png.c/ReadMNGImage/3863/Coder: enter ReadMNGImage() 14:44:59 0:01 0.000u 18511 png.c/ReadMNGImage/3961/Coder: Reading MNG chunk type JHDR, length: 16 14:44:59 0:01 0.000u...
-
This is a JNG reader issue. I hope that Glenn will fix it. gm convert -debug coder,exception 20.crashes.png null: 14:36:50 0:01 0.000u 18277 constitute.c/ReadImage/1601/Coder: Invoking "JNG" decoder (JPEG Network Graphics) subimage=0 subrange=0 14:36:50 0:01 0.000u 18277 png.c/ReadJNGImage/3699/Coder: enter ReadJNGImage() 14:36:50 0:01 0.000u 18277 png.c/ReadOneJNGImage/3033/Coder: enter ReadOneJNGImage() 14:36:50 0:01 0.000u 18277 png.c/ReadOneJNGImage/3089/Coder: Reading JNG chunk type JHDR, length:...
-
assertion failure in magick/pixel_cache.c:1089
-
Fixed by the attached patch to coders/sun.c and will be fixed by Mercurial Changeset 15124:493da54370aa once the repository changes are pushed to SourceForge.
-
memory allocation failure in magickmalloc
-
allocation failure in ReadWMFImage
-
Closed due to the problem being in libwmf's WMF validation (under 'wmf_scan()' function call) and not in GraphicsMagick.
-
This problem is in in libwmf itself and not within GraphicsMagick code. In the libwmf I am using, the problematic allocation occurs at line 136 of src/player.c: P->Parameters = (unsigned char*) wmf_malloc (API,(MAX_REC_SIZE(API) ) * 2 * sizeof (unsigned char)); It is obvious that several parsed values have huge sizes: (gdb) p *API $2 = {err = wmf_E_None, Head = {FileType = 1, HeaderSize = 9, Version = 12336, FileSize = 808464432, NumOfObjects = 12336, MaxRecordSize = 2133864496, NumOfParams = 12336},...
-
memory leak in ReadMATImage
-
heap buffer overflow in GetStyleTokens
-
Fixed by Mercurial changeset 15121:54f48ab2d52a.
-
null pointer dereference_in_SVGStartElement
-
Fixed by Mercurial changeset 15121:54f48ab2d52a.
-
heap buffer overflow in GetStyleTokens
-
Fixed by Mercurial changeset 15121:54f48ab2d52a.
-
heap use after free in CloseBlob
-
I am able to reproduce this issue. Assigned to Glenn to look at.
-
This problem can no longer be reproduced with current Mercurial sources.
-
memory leak in ReadOneJNGImage
-
memory leak in ReadJNGImage
-
This problem can no longer be reproduced with current Mercurial sources.
-
This issue no longer exists with current Mercurial sources.
-
memory leak in ReadMNGImage
-
This issue can no longer be reproduced with current GraphicsMagick sources.
-
assertion failure in WriteBlob
-
This issue was already fixed in GraphicsMagick Mercurial on August 11th.
-
memory leak in CloneImage
-
On Thu, 27 Jul 2017, Stefano CossuP wrote: Bob, Thank you for your response. I think that for this case we may be able to disallow the use of PSD files altogether to avoid similar issues. However, I wonder (not knowing anything about your development framework) how GM is supporting its own implementation of PSD rather than relying on some shared library that is used e.g. by IM, Gimp, etc. Just curious. There is no PSD library available. It would be fantastic if one did exist. Instead IM, GM, and...
-
On Wed, 26 Jul 2017, Stefano CossuP wrote: Hello, Looking at this issue in Homebrew: [1] and these GM release notes: [2] it seems like the PSD codec is considered "broken" and therefore removed from the default compile options of GraphicsMagick. I would like to know what "broken" means in this case, i.e. what the observed issues with this codec are and whether or not not it is recommended for a production scenario (I assume not?); as well as if there is a viable path to fix the issue. In this case...
-
On Sun, 9 Jul 2017, Arthur Peabody wrote: I want to add text to the bottom of an image, for example: convert -gravity south -draw "text 1,1 'comment' scale 9,9 " input.jpeg output.jpeg The 'scale' argument in -draw makes no difference in the size of the text that ends up in output.jpeg. 'convert' doesn't object, but I must be doing something wrong. The drawing primitives are patterned after SVG. The scale request applies to drawing commands which come after the request (not before) and are applying...
-
On Tue, 4 Jul 2017, Mateusz wrote: Thanks, Martin! Unfortunately, I’m not knwledgeable enough to be able to test the patch myself. Hopefully @Bfriesen can decide positively on its inclusion based on its usefulness and low complexity. A prepared source patch which works with GraphicsMagick and is offered under its existing MIT/X11-style license would be appreciated. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://...
-
One possible null pointer dereference vulnerability in GraphicsMagick-1.3.25/coders/png.c
-
Thanks for reporting this, and for the patch.
-
TclMagick: 64-bit portability issue
-
Your patch is now applied in Mercurial.
-
TclMagick: memory access error; possible segfault
-
TclMagick: memory access error; possible segfault
-
This problem is now fixed in Mercurial. Thanks for reporting the issue and providing a patch.
-
One possible buffer overflow vulnerability in GraphicsMagick-1.3.25/coders/pict.c:ReadPICTImage()
-
The issue was larger than described and so I made more changes than in your patch. Please double-check Mercurial changeset b1afa3e8f0ab and make sure that it solves the issue.
-
One possible buffer overflow vulnerability in GraphicsMagick-1.3.25/coders/pict.c:ReadPICTImage()
-
Thanks for reporting this. I wonder why Coverity has not reported such obvious issues?
-
Rather oddly, the GraphicsMagick Image structure does not store 'quality' and so quality is only stored in an ImageInfo structure used while writing the image (this attribute will eventually be added). After some investigation, I see if the attribute 'JPEG-Quality' is defined, then the value of this attibute takes precedence over the value stored in ImageInfo. The 'JPEG-Quality' attribute became defined when the JPEG file was first read. This attribute is peculiar to JPEG. The attribute may be deleted...
-
Consider a small patch to log.mgk
Oh no! Some styles failed to load. 😵