memory allocation failure in AcquireMagickMemory (memory.c) different from #267 #271
Comments
|
This is likely a problem with libASAN trying to allocate a huge array. With ASAN, we get expected results: To prevent DOS due to unreasonably large image dimensions, add image width / height limits in the ImageMagick security policy @ http://www.imagemagick.org/script/security-policy.php. |
|
same as here: |
|
I can't reproduce after enabling the security policy described here: |
|
I was unable to reproduce with the provided testcase, but after enabling the security policy another round of fuzzing turned on the issue. Before to proceed I'd like to a confirm that the list policy is what we want before filiing these types of bug: |
|
The stacktrace is the same at comment 0 |
|
Your policy is ok for fuzzing. We're using ImageMagick 7.0.3-1 and we get expected results with your test image: |
I really don't know what you mean by 7.0.3-1 since the latest available I can see here is 7.0.3-0 |
|
See pending release @ http://www.imagemagick.org/download/beta. Or grab the latest source from git master. |
|
I'm re-checking. |
|
I can reproduce with the latest 7.0.3-2 (security policy enabled) Interesting trace: Testcase: |
|
Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ http://www.imagemagick.org/download/beta/ by sometime tomorrow. |
|
This issue is still unfixed to me (re-tested on a version which includes the commit fix). Interesting trace: Reproducer: |
|
Can you give it another try @asarubbo? |
|
I'll fuzz the next release as well... |
|
the issue is still present on 7.0.4.9 |
|
An updated testcase to see the issue: |
|
We.re using ImageMagick 7.0.5-4. It returns: Does it fail for you with 7.0.5-4? The PCX source code in 7.0.4-9 and 7.0.5-4 are identical. |
|
yes, it does. |
|
We're using afl-clang and valgrind on Fedora and CentOS, neither report an error. We tried under Windows and the command completed without complaint. |
|
Did you try to enable asan? I noticed that in the above comments you had the same issue: |
|
Yes, we use the -fsanitize=address flag. If you have other compiler flags we should enable, let us know. |
|
I really don't know how make you able to reproduce the issue. I was asked to give another try...well the past testcase does not work but another round of fuzzing turned up the issue again. |
|
Understood. We appreciate your efforts but as you realize, we cannot provide a patch if we cannot reproduce the problem. |
|
Could it be rather an asan problem? I have not it enabled: (gdb) n So this is just memory_methods.acquire_memory_handler is just malloc for me which correctly returns NULL as I have not 16G memory on this system. If I would have enough memory, then it would return pointer to it. Not sure what could went wrong there. @asarubbo, what is asan actually telling us? See also |
|
can you retry with the attached testcase? it works for me with 7.0.6.5 |
|
You are getting an allocation error because the size of the colormap is ridiculous high. On our systems we can allocate this but it then fails at a later moment. Can we close this issue @asarubbo? |
|
if it is fine for you, it is fine for me too. |
A crafted image causes a memory allocation failure.
Reproduce with: identify $FILE
I'm attaching the testcase as a zip because of the github's limitation.
Tested on 7.0.3.0
2.crashes.zip
The text was updated successfully, but these errors were encountered: