Under various error conditions the image width would not be set to 0
which is currently required for the loader code to behave properly.
In particular, png_read_end() should not be called in error cases.
This would cause a longjump which would exit without setting im->w to 0.
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>.
Kim Woelders
Alexander Volkov
Tobias Stoeckmann