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>
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.
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.
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:
^~~~
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.
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>.
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
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.
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.
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
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.
This reverts commit a104e317ce.
Breaks image loading in certain situations.
It seems that some loaders may return 0 even when load() "succeeds".
This appears to happen with the jpeg loader when not loading data
immediately (but only reading the header).
In this case jpeg_finish_decompress() exits via _JPEGFatalErrorHandler()
-> longjmp() causing the return code to be 0.
The fix reverted here is probably basically correct, but it will have to
wait until the loaders are fixed to behave properly.
Prevents:
==22831== Conditional jump or move depends on uninitialised value(s)
==22831== at 0x634F040: load (loader_gif.c:181)
==22831== by 0x1F7D7B3: __imlib_LoadImage (image.c:1041)
==22831== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==22831== by 0x40F47B: feh_load_image (imlib.c:252)
==22831== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==22831== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==22831== by 0x421869: init_slideshow_mode (slideshow.c:62)
==22831== by 0x418F13: main (main.c:78)
==22831==
==22831== Use of uninitialised value of size 8
==22831== at 0x634F0F4: load (loader_gif.c:190)
==22831== by 0x1F7D7B3: __imlib_LoadImage (image.c:1041)
==22831== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==22831== by 0x40F47B: feh_load_image (imlib.c:252)
==22831== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==22831== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==22831== by 0x421869: init_slideshow_mode (slideshow.c:62)
==22831== by 0x418F13: main (main.c:78)
==22831==
==22831== Use of uninitialised value of size 8
==22831== at 0x634F122: load (loader_gif.c:191)
==22831== by 0x1F7D7B3: __imlib_LoadImage (image.c:1041)
==22831== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==22831== by 0x40F47B: feh_load_image (imlib.c:252)
==22831== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==22831== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==22831== by 0x421869: init_slideshow_mode (slideshow.c:62)
==22831== by 0x418F13: main (main.c:78)
==22831==
==22831== Use of uninitialised value of size 8
==22831== at 0x634F151: load (loader_gif.c:192)
==22831== by 0x1F7D7B3: __imlib_LoadImage (image.c:1041)
==22831== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==22831== by 0x40F47B: feh_load_image (imlib.c:252)
==22831== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==22831== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==22831== by 0x421869: init_slideshow_mode (slideshow.c:62)
==22831== by 0x418F13: main (main.c:78)
==22831==
when opening id:000001,orig:smaller-animated.gif with feh.
Tobias Stoeckmann
Kim Woelders
Yuriy M. Kaminskiy
Alexander Smirnov
Bernhard Übelacker
Quentin Rameau
FRIGN
Chloe Kudryavtsev
Fabian Keil