[Bug 761670] New: jpegdec: Possible endless loop if file is corrupt

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=761670

            Bug ID: 761670
           Summary: jpegdec: Possible endless loop if file is corrupt
    Classification: Platform
           Product: GStreamer
           Version: 1.6.3
                OS: Linux
            Status: NEW
          Severity: major
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: friemann at gnome.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 320572
  --> https://bugzilla.gnome.org/attachment.cgi?id=320572&action=edit
the jpeg file triggering this

Today I noticed tracker-extract using 100% for hours on a JPG file I had on my
disk.

The (attached) file is actually a corrupt file I received some time ago from a
bug report in eog. It's part of a suite of image files that were created using
some new data fuzzing tool: http://lcamtuf.coredump.cx/afl/demo/

When tracker-extract started working on it, it's JPEG extraction module failed,
however it then falls back to its GStreamer module where it starts using 100%
CPU. Turns out it's easy to reproduce with GStreamer alone: gst-launch-1.0
filesrc location=<filename> ! jpegdec ! autovideosink

Debugging it, it looks like gst_jpeg_dec_fill_input_buffer is passing the file
data over and over again into the decoder instead of reporting EOF/EOS. The
decoder isn't noticing the problem as it is waiting for a SOF or a EOI JPEG
marker (both are missing in the file) and thus is looping endlessly over the
same image data.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.