Summary:
This is more secure way of using shared memory because
it's visible only to the X server and the application.
Reviewers: kwo
Reviewed By: kwo
Differential Revision: https://phab.enlightenment.org/D5788
Summary:
It enhances the code, because __imlib_ShmDestroyXImage() is symmetrical
to __imlib_ShmGetXImage(), while __imlib_ShmDetach() looks unrelated.
Reviewers: kwo
Reviewed By: kwo
Differential Revision: https://phab.enlightenment.org/D5787
Summary:
This check actually refers to the internal implementation
and should not be done outside this function.
Reviewers: kwo
Reviewed By: kwo
Differential Revision: https://phab.enlightenment.org/D5783
Apparently, when using XShmGetImage to get an XImage for a (non-root?)
window, the image no longer includes subwindows (like when using
IncludeInferiors in GC).
When using XGetImage the XImage still includes subwindows.
imlib_create_scaled_image_from_drawable() (as opposed to
imlib_create_image_from_drawable() ) is implemented in such a way
that the drawable to be grabbed is always copied to a pixmap first.
This way we always get the "IncludeInferiors" type grab we most likely
want here.
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.
Kim Woelders
Alexander Volkov
Tobias Stoeckmann
Yuriy M. Kaminskiy
Alexander Smirnov
Bernhard Übelacker