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.
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.
Prevents tons of:
==10646== Conditional jump or move depends on uninitialised value(s)
==10646== at 0x4F7D30C: png_write_find_filter (pngwutil.c:2578)
==10646== by 0x4F7568F: png_write_row (pngwrite.c:827)
==10646== by 0x4F751B0: png_write_rows (pngwrite.c:587)
==10646== by 0x4D40C7D: save (loader_png.c:373)
==10646== by 0x1297084: __imlib_SaveImage (image.c:1282)
==10646== by 0x124252B: imlib_save_image (api.c:4615)
==10646== by 0x401990: main (imlib2_conv.c:74)
when trying to convert id:000134,src:000105,op:havoc,rep:32.
Prevents an integer overflow later on that resulted in a datasize of
18446744073709551575 for id:000131,src:000104,op:havoc,rep:32,+cov
whose actual size is 48 byte.
Fixes:
==14822== Conditional jump or move depends on uninitialised value(s)
==14822== at 0x4E08376: load (loader_tiff.c:285)
==14822== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==14822== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==14822== by 0x40F47B: feh_load_image (imlib.c:252)
==14822== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==14822== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==14822== by 0x421869: init_slideshow_mode (slideshow.c:62)
==14822== by 0x418F13: main (main.c:78)
==14822==
==14822== Conditional jump or move depends on uninitialised value(s)
==14822== at 0x4E083BC: load (loader_tiff.c:285)
==14822== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==14822== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==14822== by 0x40F47B: feh_load_image (imlib.c:252)
==14822== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==14822== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==14822== by 0x421869: init_slideshow_mode (slideshow.c:62)
==14822== by 0x418F13: main (main.c:78)
==14822==
when scaling id:000407,src:000226,op:havoc,rep:32 in feh.
Was supposed to fixes:
==24603== Invalid read of size 1
==24603== at 0x1FCD748: __imlib_ScaleAARGB (scale.c:990)
==24603== by 0x1F9BF81: __imlib_RenderImage (rend.c:405)
==24603== by 0x1F0F82C: imlib_render_image_part_on_drawable_at_size (api.c:1886)
==24603== by 0x40CD75: gib_imlib_render_image_part_on_drawable_at_size (gib_imlib.c:231)
==24603== by 0x42C732: winwidget_render_image (winwidget.c:576)
==24603== by 0x417ACA: feh_event_handle_keypress (keyevents.c:598)
==24603== by 0x4190DE: feh_main_iteration (main.c:119)
==24603== by 0x418F45: main (main.c:82)
==24603== Address 0x4824832 is 3,650 bytes inside a block of size 4,096 free'd
==24603== at 0x103E498: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==24603== by 0x234157D: fclose (fclose.c:62)
==24603== by 0x5B3CD7F: load (loader_pnm.c:540)
==24603== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==24603== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==24603== by 0x40F47B: feh_load_image (imlib.c:252)
==24603== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==24603== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==24603== by 0x421869: init_slideshow_mode (slideshow.c:62)
==24603== by 0x418F13: main (main.c:78)
when using feh to scale input/queue/id:000407,src:000226,op:havoc,rep:32
but isn't sufficient by itself.
Still looks correct to me, though.
Prevents invalid reads and unreasonably large memory allocations
with input/queue/id:000210,src:000114,op:int32,pos:3,val:be:+32,+cov:
==20321== Invalid read of size 1
==20321== at 0x1FCDB16: __imlib_ScaleAARGB (scale.c:1043)
==20321== by 0x1F9BF81: __imlib_RenderImage (rend.c:409)
==20321== by 0x1F0F82C: imlib_render_image_part_on_drawable_at_size (api.c:1886)
==20321== by 0x40CD75: gib_imlib_render_image_part_on_drawable_at_size (gib_imlib.c:231)
==20321== by 0x42C732: winwidget_render_image (winwidget.c:576)
==20321== by 0x417ACA: feh_event_handle_keypress (keyevents.c:598)
==20321== by 0x4190DE: feh_main_iteration (main.c:119)
==20321== by 0x418F45: main (main.c:82)
==20321== Address 0x3a12e034 is 12 bytes before a block of size 1,965,846,976 alloc'd
==20321== at 0x103D293: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==20321== by 0x5B3D1F1: load (loader_pnm.c:149)
==20321== by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==20321== by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==20321== by 0x40F47B: feh_load_image (imlib.c:252)
==20321== by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==20321== by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==20321== by 0x421869: init_slideshow_mode (slideshow.c:62)
==20321== by 0x418F13: main (main.c:78)
Summary:
From giflib-5.1.0's NEWS:
"A small change to the API: DGifClose() and EGifClose() now take a
pointer-to-int second argument (like the corresponding openers)
where a diagnostic code will be deposited when they return
GIF_ERROR."
Test Plan:
I've built imlib2 against giflib-4.2.3 and 5.1.0 and opened a few
gif files with feh.
Reviewers: kwo
Reviewed By: kwo
Differential Revision: https://phab.enlightenment.org/D1529
When building out-of-source, the headers are located in subdirectories
in $(top_srcdir) rather than $(top_builddir). Adjust AM_CPPFLAGS
accordingly.
URL: https://bugs.gentoo.org/510522
This fixes warnings with newer compilers/distros that enable warning
flags by default:
loader_zlib.c: In function 'uncompress_file':
loader_zlib.c:33:17: warning: ignoring return value of 'write',
declared with attribute warn_unused_result [-Wunused-result]
write(dest, outbuf, bytes);
^
- Eliminate deprecated AC_TRY_CPP.
- Use pkg-config in stead of freetype-config to get freetype info.
- Eliminate my_includes/my_libs.
- Clean up include paths.
Drawing of the closing line could be skipped depending on the specific
vertex coordinates (and order).
Can't say that I undestand the code completely but this change seems
to fix the problem, and I don't think it can cause trouble.
Revert previous patch generated by badnull.cocci script, and apply the new one.
The main difference is that assert and assert-like functions are not touched
anymore.
SVN revision: 51650
Apply badzero.cocci, badnull.coci and badnull2.cocci
This should convert all cases where there's a comparison to NULL to simpler
forms. This patch applies the following transformations:
code before patch ||code after patch
===============================================================
return a == NULL; return !a;
return a != NULL; return !!a;
func(a == NULL); func(!a);
func(a != NULL); func(!!a);
b = a == NULL; b = !a;
b = a != NULL; b = !!a;
b = a == NULL ? c : d; b = !a ? c : d;
b = a != NULL ? c : d; b = a ? c : d;
other cases:
a == NULL !a
a != NULL a
SVN revision: 51487
Change calls to malloc + memset to calloc whenever an automatic conversion can
be done.
Possible candidates are not treated here, only the ones we can be sure the
conversion is safe.
SVN revision: 51078
* Remove vim modelines:
find . -name '*.[chx]' -exec sed -i '/\/\*$/ {N;N;/ \* vim:ts/d}' \{\} \;
find . -name '*.[chx]' -exec sed -i '/\/[\*\/] *vim:/d' \{\} \;
* Remove leading blank lines:
find . -name '*.[cxh]' -exec sed -i '/./,$!d'
If you use vim, use this in your .vimrc:
set ts=8 sw=3 sts=8 expandtab cino=>5n-3f0^-2{2(0W1st0
SVN revision: 50816
There are almost certainly still issues to be fixed, particularly
around progess() and certain combinations of orientation and tiling.
SVN revision: 50515
The notnull.cocci script from Coccinelle finds places where you check if a
variable is NULL, but it's known not to be NULL. The check can be safely
removed. For example, this code would be caught by notnull:
if (!var) return;
if (var && var->fld) { ... }
It's needless to check again if var is not NULL because if it's in fact NULL,
it would have returned on the previous "if". This commit removes all the
trivial places where this pattern happens. Another patch will be generated for
the more complex cases.
SVN revision: 50241
As far as I can tell this fixes building on x86_64 with e.g.
'./configure --enable-mmx CFLAGS=-m32" or "rpmbuild --target i386 ..."
without breaking anything.
SVN revision: 41667
Kim Woelders
Alexander Volkov
Tobias Stoeckmann
Yuriy M. Kaminskiy
Alexander Smirnov
Bernhard Übelacker
Quentin Rameau
FRIGN
Chloe Kudryavtsev
Fabian Keil
Heiko Becker
Michał Górny
Mike Frysinger
Lucas De Marchi
Carsten Haitzler