Package: imlib2 / 1.4.5-1+deb7u2
Metadata
Package | Version | Patches format |
---|---|---|
imlib2 | 1.4.5-1+deb7u2 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
001 removed_data_dir.diff | (download) |
Makefile.am |
2 1 + 1 - 0 ! |
--- |
CVE 2014 9762.patch | (download) |
src/modules/loaders/loader_gif.c |
13 13 + 0 - 0 ! |
cve-2014-9762 Fix segmentation fault on images without colormap. |
CVE 2014 9763.patch | (download) |
src/modules/loaders/loader_pnm.c |
10 5 + 5 - 0 ! |
cve-2014-9763 Prevent division-by-zero crashes. |
CVE 2014 9764.patch | (download) |
src/modules/loaders/loader_gif.c |
5 5 + 0 - 0 ! |
cve-2014-9764 Fix segfault when opening specially crafted input with feh. |
CVE 2011 5326.patch | (download) |
src/lib/ellipse.c |
24 24 + 0 - 0 ! |
fix potential divide-by-zero in imlib_image_draw_ellipse(). 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 |
CVE 2014 9771.patch | (download) |
src/lib/image.h |
7 5 + 2 - 0 ! |
make image_dimensions_ok() more restrictive 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) |
CVE 2016 3993.patch | (download) |
src/lib/updates.c |
2 1 + 1 - 0 ! |
fix off-by-one oob read in __imlib_mergeupdate(). Patch by Yuriy M. Kaminskiy. https://bugs.debian.org/819818 |
CVE 2016 3994.patch | (download) |
src/modules/loaders/loader_gif.c |
31 17 + 14 - 0 ! |
gif loader: fix out-of-bound reads from colormap. Bug-Debian: http://bugs.debian.org/785369 Note: removes all special-casing from the inner loop, optimize for common case. |
CVE 2016 4024.patch | (download) |
src/lib/image.h |
3 2 + 1 - 0 ! |
fix integer overflow resulting in insufficient heap allocation 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. |