Bug 1279153 - libopenraw-pixbuf-loader causes SEGV in nautilus
libopenraw-pixbuf-loader causes SEGV in nautilus
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libopenraw (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Wim Taymans
Desktop QE
Depends On: 1285603 1279152
  Show dependency treegraph
Reported: 2015-11-08 02:56 EST by Yaakov Selkowitz
Modified: 2016-11-03 21:31 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1279152
: 1285603 (view as bug list)
Last Closed: 2016-11-03 21:31:29 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Yaakov Selkowitz 2015-11-08 02:56:38 EST
+++ This bug was initially created as a clone of Bug #1279152 +++

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
0. Update to 7.2 HTB.
1. install libopenraw-pixbuf-loader (in Optional)
2. download (into e.g. ~/Downloads) a RAW file not supported by libopenraw, e.g. http://www.rawsamples.ch/raws/olympus/sp350/RAW_OLYMPUS_SP350.ORF
3. start/open nautilus
4. in Preferences->Preview, make sure "Show thumbnails" is not "Never" and "Only for files smaller than" is set to at least 100MB (the above example is ~12MB)
5. then browse to the folder (e.g. ~/Downloads) containing the RAW file.

Actual results:

Expected results:
Error message to stderr, no thumbnail generated.

Description of problem:
gdk_pixbuf_loader_close is documented to set a non-NULL @error when returning FALSE, but lines 821-831 allow the possibility of returning FALSE without setting @error:


libgnome-desktop's _gdk_pixbuf_new_from_uri_at_scale (used by Nautilus to generate thumbnails for image formats supported by GdkPixbuf) depends on the documented behaviour by accessing error->message without checking that error != NULL:


However, libopenraw's gdk_pixbuf__or_image_stop_load, which is the vfunc called by gdk_pixbuf_loader_close, completely ignores @error:


So, when faced with a RAW image that libopenraw does not support (which, at least in 0.0.9 are many, given that there are four years of yet unreleased development in upstream git), libopenraw-pixbuf-loader causes gdk_pixbuf_loader_close to return FALSE but does *not* set @error as promised.  The result is a NULL dereference in libgnome-desktop causing nautilus to SEGV.

Ultimately, there is plenty of blame to go around here:

* libopenraw's gdk_pixbuf__or_image_stop_load should conform with the documented requirement of gdk_pixbuf_loader close along the lines of the following:

--- a/gnome/pixbuf-loader.c
+++ b/gnome/pixbuf-loader.c
@@ -98,7 +98,6 @@ gdk_pixbuf__or_image_stop_load (gpointer

     GdkPixbuf *pixbuf = NULL;
     ORRawFileRef raw_file = NULL;
-    (void)error;

     raw_file = or_rawfile_new_from_memory(context->data->data, context->data->len,
@@ -129,6 +128,11 @@ gdk_pixbuf__or_image_stop_load (gpointer
         result = TRUE;
+    } else if (error) {
+        g_set_error (error,
+                     GDK_PIXBUF_ERROR,
+                     GDK_PIXBUF_ERROR_FAILED,
+                     "Unable to load RAW file");
* gdk_pixbuf_loader_close must conform with its documentation and assure that (a non-NULL) @error is always set when returning FALSE, in case a(nother) loader's stop_load vfunc does not conform.

* it could be argued that libgnome-desktop should check for error != NULL before error->message, but OTOH gdk-pixbuf's documentation does indicate that it is a safe assumption to make.

Additional info:
I believe this is a regression in 7.2, and would not affect 7.1, as libgnome-desktop 3.8 did not use @error:

Comment 5 errata-xmlrpc 2016-11-03 21:31:29 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.