+++ This bug was initially created as a clone of Bug #17731 +++ A CVE was requested for an integer overflow that affects gtk+ and several apps: http://openwall.com/lists/oss-security/2016/02/10/2 A commit upstream in gtk+ to fix it is linked in the message above. Patched eog packages uploaded for Mageia 5 and Cauldron. Suggested advisory: ======================== Updated eog packages fix security vulnerability: Due to a logic error, an attempt to allocate a large block of memory fails in create_surface_from_pixbuf, leading to a crash of eog (CVE-2013-7447). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-7447 http://openwall.com/lists/oss-security/2016/02/10/6 ======================== Updated packages in core/updates_testing: ======================== eog-3.14.3-1.1.mga5 libeog-gir3.0-3.14.3-1.1.mga5 eog-devel-3.14.3-1.1.mga5 from eog-3.14.3-1.1.mga5.src.rpm
Testing MGA5 x64 real h/w: OK Curiosity: Despite already having and using occasdionally EOG, I did not have lib64eog-gir3.0 . I installed it for the update, but clearly it is not being used here. Updated to: lib64eog-gir3.0-3.14.3-1.1.mga5 eog-3.14.3-1.1.mga5 Viewed a mixed bag of image types, fullscreen, slideshow, all seems OK.
CC: (none) => lewyssmithWhiteboard: (none) => MGA5-64-OK
mga5 i586 in virtualbox Mate Before updating ran a check on a large PNG file (27000x27000). The image displayed for several seconds then vanished: [lcl@cursa ~]$ eog big.png ** Gdk:ERROR:gdkcairo.c:193:gdk_cairo_surface_paint_pixbuf: assertion failed: (cairo_image_surface_get_format (surface) == CAIRO_FORMAT_RGB24 || cairo_image_surface_get_format (surface) == CAIRO_FORMAT_ARGB32) Abort Performed the update and tested eog against several different image types. Used the image and display manipulation functions, ran the slideshow and edited preferences to alter the period. Everything working fine except with the 27000x27000 PNG image. It rendered alright but crashed after 4 or 5 seconds. That looks similar to bug #17739 which was fixed for eom. The current problem manifests itself on x86_64 as well. However eog looks good for this update.
CC: (none) => tarazed25
Whiteboard: MGA5-64-OK => MGA5-64-OK MGA5-32-OK
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Sorry, I have to retract that. Somehow overlooked the point of the update. The big.png test is the PoC and shows that the update does not fix the problem.
Keywords: validated_update => (none)
Whiteboard: MGA5-64-OK MGA5-32-OK => MGA5-64-OK
@Lewis. And apologies to you also - I am going to have to cancel the 64bit OK. After updating eog and lib64eog-gir3.0: [lcl@vega ~]$ eog big.png (eog:2269): Gdk-WARNING **: eog: Fatal IO error 2 (No such file or directory) on X server :2. eog tried to render the image but failed after a few seconds. The point of failure looks different from that encountered in the 32bit test so may well be a different bug. Shall file a new bug against it with an strace and see what transpires. All other tests succeed so I am in a bit of a quandary about the status of this update for 64bits. Has the original bug been squashed or not? Safer to let it stand.
(In reply to Len Lawrence from comment #4) > @Lewis. And apologies to you also - I am going to have to cancel the 64bit > OK. Quite agree. You have done a marvelous job here, much more thorough than mine. I overlooked the "memory allocation integer overflow in gdk_cairo_set_source_pixbuf on large pixbufs" issue. Well dug out. http://openwall.com/lists/oss-security/2016/02/10/6 -> https://bugzilla.gnome.org/show_bug.cgi?id=703220 Not sure about whether whether to let this bug stand 'awaiting feedback' i.e. another correction; or squash it until that correction arrives, new bug. David will know.
Created attachment 7462 [details] Large image used for eom and eog tests
Whiteboard: MGA5-64-OK => (none)
Bug https://bugs.mageia.org/show_bug.cgi?id=17778 filed for the error report noted in comment #4.
So how do the outputs/traces compare before and after the update? Is there a difference between 32-bit and 64-bit?
Only one of the tests has an strace file. Terminal output: i586 VM Before update: ** Gdk:ERROR:gdkcairo.c:193:gdk_cairo_surface_paint_pixbuf: assertion failed: (cairo_image_surface_get_format (surface) == CAIRO_FORMAT_RGB24 || cairo_image_surface_get_format (surface) == CAIRO_FORMAT_ARGB32) Abort Afterwards: (eog:2269): Gdk-WARNING **: eog: Fatal IO error 2 (No such file or directory) on X server :2. x86_64 both before and afterwards: (eog:30041): Gdk-WARNING **: eog: Fatal IO error 2 (No such file or directory) on X server :2.0. For x86_64 I had no record of the before update message so downgraded and tried the test again and found the same behaviour. Tried this for the before update version on 64-bit hardware: [lcl@vega ~]$ gthumb big.png (gthumb:31361): Gtk-WARNING **: Failed to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files (gthumb:31361): Gtk-CRITICAL **: gtk_widget_set_visible: assertion 'GTK_IS_WIDGET (widget)' failed Segmentation fault which makes me wonder if things might be different on the GNOME desktop. Off to try that....
Thanks for the confirmation, that's the results that I expected. I would expect this overflow to only reasonably be able to be triggered on 32-bit, and you showed that it is fixed, but uncovered another bug. It'd be helpful to know if the new bug you uncovered still exists in Cauldron.
Going native had no effect on x86_64. i.e. The error message was the same for eog. So that is an OK for 64-bit systems. Thanks for the clarification David.
Whiteboard: (none) => has_procedure MGA5-64-OK
URL: (none) => http://lwn.net/Vulnerabilities/675834/
Sorry David. I don't have a Cauldron installation any more. I was thinking of taking a break and rebuilding it. Will report back on one of the mailing lists unless somebody beats me to it.
I might as well report it here as well. Cauldron installed: eog-3.19.90-1.mga6 This displays the big.png but without the window frame and menu and it crashes after several seconds with - (eog:8426): Gdk-WARNING **: eog: Fatal IO error 2 (No such file or directory) on X server :0. So the bug has propagated to later versions. eom faults in the same way after successfully displaying the image (with the window decorations in this case). $ eom big.png eom: Fatal IO error 2 (No such file or directory) on X server :0. I shall run an strace in the morning and add this report to bugzilla. Middle of the night here.
Keywords: (none) => validated_updateCC: (none) => davidwhodginsWhiteboard: has_procedure MGA5-64-OK => has_procedure MGA5-64-OK advisory
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0074.html
Status: NEW => RESOLVEDResolution: (none) => FIXED