Activity for Bob Friesenhahn
-
Bob Friesenhahn posted a comment on ticket #534
Since you are invoking InitializeMagick(), the most likely cause of problems like this could be if there are multiple GraphicsMagick shared libraries/headers and the wrong ones are being used when compiling, linking, or at run-time. There is also the possibility of mixing header files from two different GraphicsMagick builds. CMake might not be making it obvious what it is doing. At the shell prompt do: export MAGICK_DEBUG=configure and run your program from that shell prompt. You should see a trace...
-
heap-buffer-overflow in AcquireCacheNexus
-
Currently 'depth' is set by the decoder and it is more of an estimate of the minimum depth that the writer should use to re-create the image in a direct (not colormapped) representation without loss, without inflating the storage size, and without surprising the user. The user has a notion that if they read from a 1 bit/pixel image and paste a deep RGB image on it that the output file should use a depth which will not lose the deep RGB image. This is why the lowest depth level set is 8. A depth level...
-
heap-buffer-overflow bug in ReadWPGImage
-
This issue is fixed by Mercurial changeset 15304:8e3d2264109c. There is an error in a hard-coded offset which was one-off from what it should have been, causing a read one past the end of a character array.
-
heap-buffer-overflow in ReadOneJNGImage
-
global-buffer-overflow in ReadPALMImage
-
This problem is fixed by Mercurial changeset 15303:60932931559a. Thank you very much for bringing this issue to our attention.
-
global-buffer-overflow in ReadPALMImage
-
I was not able to reproduce this in a Q16 build but it is evident in a Q8 build.
-
Please make a 1.3.27 release for security fixes
-
The release is done. Releasing requires far more than applying a "tag" since it required about 5 hours of my time.
-
GraphicsMagick 1.3.27 is now available
-
BMP happens to be a format which can have varying depths depending on the channel. Some formats have no inherent depth, or we have no way to ascertain the original depth. The main concern regarding depth is that depth is used in different ways. The 'depth' attribute may also be used when storing an image. Some writers support many sub-formats and depth may be used to influence which subformat is used. PseudoClass/colormapped images pose the issue that an image using only a few bits/sample could present...
-
heap-buffer-overflow in WriteOnePNGImage
-
This issue is fixed by Mercurial changeset 15291:5b8414c0d0c4. Since this is a very small read over-run of a heap buffer, and because usually the underlying allocation size is larger than what was requested, this problem should usually be benign. Thank you for reporting this problem.
-
The png.c problem could be handled by a single "patch", which might include some small new features but otherwise addresses many issues beyond those described by CVEs. Regardless, unless something unexpected happens I will try to cut the next release this weekend.
-
heap-buffer-overflow in MagickBitStreamMSBWrite
-
This problem is fixed by Mercurial changeset 15290:f1c418ef0260. Thanks for reporting this issue.
-
The file extracted from your zip file does reproduce the problem.
-
Please re-attach your "pam.png" in a zip archive. I am not able to reproduce the problem with the current file. FYI, SourceForge rewrites common formats like GIF and PNG so they will be destroyed as test-cases unless they are wrapped up.
-
I agree that we are past due for a release. It would be wrong to focus on just one issue afflicting png.c since many issues have been fixed in png.c since the last release.
-
Unfortunately the project does not have enough resources (available time) to apply for CVEs any more. I suggest that you apply for the CVEs yourself or find an interested party to do so.
-
heap-buffer-overflow
-
heap-buffer-overflow
-
Fixed by Mercurial changeset 15285:1366f2dd9931. Thanks for the report.
-
heap-buffer-overflow
-
This problem is resolved by Mercurial changeset 15284:460ef5e858ad. Thank you very much for the report.
-
heap-buffer-overflow
-
This problem is fixed by Mercurial changeset 15283:a9c425688397. Thank you for the report!
-
Add Magick::Image::autoOrient() method to Magick++ library
-
Thanks for your contribution. It is now in Mercurial as part of changeset 15278:c8703f8e760b.
-
Fixed now in Mercurial and should show up on the web site shortly.
-
[web] Download sites: non-existent country
-
SVG file with width, height in inches is not rendered to the correct output size when DPI is other than 72.
-
Mercurial changeset 15258:567f87e1410d adds EXIF and ICC metadata support starting with libwebp 0.5.0.
-
WEBP color saturation degradation
-
Add EXIF/ICC metadata support to WebP coder
-
Your patch is incorporated in Mercurial changeset 15258:567f87e1410d. Additional work was required since the changes required libwebp 0.5.0 but we support compilation back to 0.1.99. Thank you very much for this patch.
-
Heap overflow in source-gra/coders/png.c
-
This issue is resolved by Mercurial changeset 15257:ad6a2e30c25b. Thank you very much for the report.
-
After the addition of Mercurial changesets 15247:75245a215fff, 15248:fcd3ed3394f6, 15249:135bdcb88b8d, 15250:2a21cda3145b, and 15251:1b9e64a8901e, this problem is definitely fixed and additional issues noticed by valgrind and ASAN are fixed as well.
-
Heap buffer overflow in AcquireCacheNexus()
-
Mercurial changesets 15161:3dc7b4e3779d and 15245:e8086faa52d0 (and possibly 15246:2b7c826d36af) seem to help in that ASAN no longer reports a heap buffer overflow. Valgrind still reports use of uninitialized data and ASAN complains bout memory leaks.
-
Null Pointer Dereference (Write) with malformed WPG Image
-
This problem is fixed by Mercurial changeset 15245:e8086faa52d0. Thank you very much for reporting it.
-
This syntax (subimage specification) is already supported for raw image formats (which require that -size be specified) in the readers. It is indeed feasible to extract a subimage after the image has already been read but there is the most benefit if the reader itself is able to support it.
-
Valid SVGfile not accepted by gm validate
-
Push operations in DrawImage can lead to negative strncpy when looking for pop
-
These issues are fixed by Mercurial changeset 15243:785758bbbfcc. Thank you for notifying us of this issue, with such a well written analysis, and with useful test-cases.
-
Issue is made public now so it can be referenced. There is a follow-on changeset 15240:da135eaedc3b which adds more checks for null pointer. Effort is under way to try to accurately detect and reject impossibly small files given the image dimensions.
-
Null pointer in
-
I changed private to Yes 5 days ago. Do you mean that you want it to remain private, or it should become public so it can be referenced?
-
On Wed, 25 Oct 2017, Vicente wrote: Both images were correctly read on Rasbian Jessie. What can I do? Assuming that you are using GraphicsMagick binaries from Rasbian Strecht I recommend that you open a bug report for this package in the bug tracker for Rasbian Strecht. Probably necessary files are missing from your system. If it is a modules-based build, then it would be necessary for "gif.la" to be included alongside "gif.so". It is possible that they accidentally left those files out while packaging...
-
This issue (use of null pointer) is addressed by Mercurial changeset 15239:6fc54b6d2be8. It is verfied that pixel limits are enforced and reported properly. It seems that there should still be some rationalization of image dimensions based on file size.
-
Null pointer in
-
I don't get the NULL pointer problem, but I do see that the JNG dimensions are claimed to be 59395x24577 and a 11678007320 byte temporary file is created and passed to the JPEG reader. What is profoundly interesting is that no serious errors are reported in my testing, even under low memory conditions.
-
Null pointer in
-
On Wed, 18 Oct 2017, Swapnil Pramod Bhamat wrote: Can anyone help me to get 5 unique hex from an image using GraphicsMagick. At the moment I am not thinking of a quick way to get just the colors as a nice file. The colormap will be included in the summary output of convert image_name.png +dither -colors 5 -verbose info:- and part of the histogram MIFF comment if you do: convert image_name.png +dither -colors 5 histogram:histo.miff and so (in a rather painful way using a pipeline), it is possible...
-
Push operations in DrawImage can lead to negative strncpy when looking for pop
-
What causes you to believe that the PDF is invalid? It produces a nice purple gradient when I open it with a couple of PDF viewers.
-
On Fri, 13 Oct 2017, Dmitry Katsubo wrote: As to this post, when converting image to PDF the resultsing PDF is invalid. Please include A.jpg and A.pdf inside a zipfile or tarball (so SourceForge does not re-write the files) and attach it to this problem report so we can see what the problem is and attempt to recreate it. Thanks, Bob Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
-
The only way I could see something unexpected happening is if there are multi-character UTF-8 characters in the path. GM still does not parse individual UTF-8 characters while parsing paths. I am unable to reproduce the problem given the obviously made-up paths provided with this report.
-
gm mogrify: option -output-directory is utterly (and dangerously!) broken
-
gm mogrify: option -output-directory is utterly (and dangerously!) broken
-
I have not been able to reproduce this problem. Is it possible that your path components are UTF-8 strings (e.g. contain extended non-ASCII characters encoded as UTF-8)? % mogrify -verbose -output-directory /srv/www/www.some.domain/some/subdirectory crap MogrifyImages (0x83db008->crap): -verbose -output-directory /srv/www/www.some.domain/some/subdirectory MogrifyImage (0x83db008->crap): -verbose -output-directory /srv/www/www.some.domain/some/subdirectory crap JPEG 800x1203+0+0 DirectClass 8-bit...
-
allocation failure in ReadOnePNGImage
-
Use after free in ReadJNGImage
-
allocation failure in ReadOnePNGImage
-
This problem is fixed by Mercurial changesets 15167:cadd4b0522fa, 15218:93bdb9b30076 and 15223:df946910910d. Thanks for the report!
-
Use after free in ReadJNGImage
-
This problem is fixed by Mercurial changesets 15218:93bdb9b30076 and 15223:df946910910d. Thanks for the report!
-
gm mogrify: Wrong documentation for option -output-directory
-
Thank you for the helpful feedback. The option documentation has been improved to reflect that a file extension is automatically added if the input file lacks an extension, and the sub-directories are automatically created when needed.
-
I decided to add another fix, which by itself may be sufficient. The additional fix may be found in Mercurial changeset 15216:af829a95188a. The additional fix throws an error if there are no scenes. Valgrind is happy with it.
-
NULL Pointer Dereference in DICOM Decoder
-
Note that while the fix "works", I am not all that happy with it and am pondering using a fix at the point of origin (where the null image was produced) instead. It is possible that I could leave the existing fix in place and add another one at the point of origin. It is definitely not normal for 'image' to be null at any point in time.
-
Sorry about that. It was in one repository, but not the one at SourceForge.
-
Heap overflow in source-gra/coders/png.c
-
allocation failure in ReadOnePNGImage
-
Use after free in ReadJNGImage
-
NULL Pointer Dereference in DICOM Decoder
-
This problem is fixed by Mercurial changeset 15215:b3eca3eaa264. Thanks for the report!
-
This problem is fixed by Mercurial changeset 15214:0683f8724200. Thanks for the report!
-
Memory Allocation error due to malformed image file
-
This problem is fixed by Mercurial changeset 15213:011296e737a1. Thanks for the report!
-
memory leak in WritePNMImage
-
memory leak in ReadMNGImage
-
This problem is fixed by Mercurial changeset 15212:0d59486cb62b. Thanks for the report!
Oh no! Some styles failed to load. 😵
Please try reloading this page