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
Double free problem #673
Double free problem #673
Conversation
This way it is much easier to user logging.
Codecov Report
Continue to review full report at Codecov.
|
if realloc() is called with 0 size it may return NULL and this will be incorrectly handled as not enough memory and (also) rasterBits will be freed by realloc but we will not update it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. LGTM
|
I've analyzed this case deeper and it turns out that frames having 0 size are ignored when reading file using Although this change fixes the issue visible to user I'll report this inconsistency to GIFLib bugtracker. I expect that while reading file in both ways we should see the same number of frames. |
|
Hi @koral-- , when will be the next release that contains this fix? |
|
It is already released about month ago. |
|
Ah it's in 1.2.18. Thanks! |
If a gif has at least three frames, first with non-zero size and two others with 0 size then the lib may free one pointer twice.
I'm not sure if I've correctly understood the code but it looks like it is enough to just free rasterBits and nullify them in case of empty frame.
Also I've defined LOGE() macro for release (as NOOP) to avoid
#ifdef DEBUGevery time I need to use logging ;)The version of problematic gif added (since it is rather strange gif I've zipped it to avoid possible problems with its playback.
exploit.zip