merge original changes for 2017 #1
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Do not impose an arbitrary small buffer size limit on filenames when checking and trimming bz2 extension.
Do not impose an arbitrary small buffer size limit on filenames when checking and trimming gz extension.
Verify the color map is inbounds before indexing with it. https://bugs.debian.org/785369
Patch by Yuriy M. Kaminskiy. https://bugs.debian.org/819818
This reverts commit 16de244. Will push alternative solution.
Bug-Debian: http://bugs.debian.org/785369 Note: removes all special-casing from the inner loop, optimize for common case. Author: Yuriy M. Kaminskiy <yumkam+debian@gmail.com> Reported-By: Jakub Wilk <jwilk@debian.org> Thanks to Bernhard U:belacker <bernhardu@vr-web.de> for analysis.
Patch by Yuriy M. Kaminskiy.
Patch by Yuriy M. Kaminskiy.
And remove now unused label "finish".
Attempting to draw a 2x1 ellipse with e.g. imlib_image_draw_ellipse(x, y, 2, 1) causes a divide-by-zero. It seems happy enough to draw 1x1, 1x2 and 2x2, but not 2x1. Patch by Simon Lees. https://bugs.debian.org/639414
IMAGE_DIMENSIONS_OK ensures that image width and height are less then 46340, so that maximum number of pixels is ~2**31. Unfortunately, there are a lot of code that allocates image data with something like malloc(w * h * sizeof(DATA32)); Obviously, on 32-bit machines this results in integer overflow, insufficient heap allocation, with [massive] out-of-bounds heap overwrite. Either X_MAX should be reduced to 32767, or (w)*(h) should be checked to not exceed ULONG_MAX/sizeof(DATA32). Security implications: *) for 32-bit machines: insufficient heap allocation and heap overwrite in many image loaders, with escalation potential to remote code execution; *) for 64-bit machines: it seems, no impact.
1) ptr is DATA32 *, so (ptr-im->data) is (w * h) at most; so this condition was broken, it should've been ((ptr-im->data) >= w*h); 2) ... however, ptr != NULL and (context > 1) are only possible together, and ptr and count are incremented always together too, so there are no point to check both; leave only less expensive check.
Summary: Imlib generates masks on the client side with the bit order of the client. Set this bit order for produced XImages. Reviewers: kwo Differential Revision: https://phab.enlightenment.org/D3891
Prevents potential integer overflow -> insufficient allocation -> heap overflow scenarios.
It may not be the ideal location but it's better than image.c
There were several potential OOM crashes in __imlib_ListFilters(), __imlib_ListLoaders() and __imlib_TrimLoaderList(). The fix of __imlib_TrimLoaderList() is from patch by Yuriy M. Kaminskiy <yumkam@gmail.com>.
Attempting to read a PNM bitmap (ASCII format) would cause a lockup due to infinite loop, and in certain cases write access outside allocated memory. Fixes CVE-2016-6348 (out-of-bounds writes ... presumably - CVE text not disclosed yet). Found by Neelima Krishnan, Intel Corporation.
Found by gcc 7:
grab.c: In function ‘__imlib_GrabXImageToRGBA’:
grab.c:85:14: error: this statement may fall through [-Werror=implicit-fallthrough=]
for (y = 0; y < h; y++)
^~~
grab.c:97:11: note: here
case 24:
^~~~
It is possible to trigger out of boundary read and write accesses while parsing XPM files. 1. If the color definition is shorter than the specified cpp, i.e. characters per pixel, an out of boundary write can be triggered. The write will modify stack memory and could therefore be used to corrupt local variables or return addresses. 2. If the pixel area contains less than the required amount of characters per pixel, an out of boundary read can be triggered. This affects files with more than one character per pixel. 3. If an out of memory condition occurs, a null pointer dereference can be triggered because the variable line is reallocated if not enough memory was available. Dereferencing line with an offset would lead to yet another out of boundary write, which will lead to a segmentation fault on almost every system out there.
The code did not properly release resources in some error paths, leading to memory leaks or possible double free issues. If an image could not be loaded, some code paths check if width is 0 to determine if an error occurred. Therefore, always set width to 0 in such cases.
If imlib2 is compiled with large file support on 32 bit systems, which is not the default, the TGA loader is vulnerable to an out of boundary read due to insufficient off_t/size_t validations. If large file support is enabled, off_t is 64 bit, while size_t is the regular 32 bit on 32 bit architectures. Casting directly leads to issues with files which are larger than 4 GB. As it's unlikely to encounter such files, they will be simply ignored on such systems. 64 bit systems are not affected. Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Introduced in d5ebec2.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.