New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
|
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: