Summary:
Decompressing should be the last step, otherwise files that can't even be loaded will take unnecessarily long only to be discarded immediately.
This is in reference to [this issue for feh](https://github.com/derf/feh/issues/477) complaining about long load times in case of accidentally trying to open a big .tar.bz2 archive.
Test Plan: Ran on sample from aforementioned ticket, observed immediate response and no further ill effects.
Reviewers: kwo
Differential Revision: https://phab.enlightenment.org/D10398
The test images at https://entropymine.com/jason/bmpsuite were most
helpful.
Several features have NOT been implemented, including
- Non-square resolution
- "Bottom up" format
- PNG compression
- JPEG compression
- Huffman 1D (OS/2) compression
- 2 bpp (OS/2)
- BA file type (bitmap array - OS/2)
Summary:
... and add imlib_create_image_using_data_and_memory_function().
For example, it allows to load an image in one process and then
pass it through shared memory to another process without extra
memory copy.
Reviewers: kwo
Differential Revision: https://phab.enlightenment.org/D10222
If there are not enough pixels in the image data just fill in the first
color.
This way we will proceed without uninitialized pixel data avoiding
valgrind complaints.
Pixels with color "none" were composed using uninitialised GB values.
Although the pixels were "correct", as RGB are don't-care when A is 0,
let's not put random data in images and avoid valgrind complaints.
Thanks to Sebastien Ballet for test case.
Instead of assigning it (in different ways) in each loader, do it
centrally in __imlib_LoadImageWrapper().
And a couple of cleanups in code related to im->format.
Commit 6ef51ec4cd added some cleanup
logic, however it introduced an off-by-one bug for raw bytes in RLE.
It looks like a copy'n'paste problem:
- the check on line 426 is correct, however
- the check on line 481 has an erronous "+ 1"
In the second case, "bufptr" has already been incremented, so the
extra "+ 1" is not needed.
This bug causes some legitimate TGA files to fail to load, on the
very last pixel...
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>.
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
Olof-Joachim Frahm (欧雅福)
Alexander Volkov
Ralph Siemsen
Tobias Stoeckmann
Yuriy M. Kaminskiy
Alexander Smirnov
Bernhard Übelacker
Quentin Rameau