gnash-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3


From: Bastiaan Jacques
Subject: [Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3
Date: Wed, 24 Oct 2012 23:38:46 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0

URL:
  <http://savannah.gnu.org/bugs/?37629>

                 Summary: buffer overflow from Input::readSWFJpeg3
                 Project: Gnash - The GNU Flash player
            Submitted by: bjacques
            Submitted on: Thu 25 Oct 2012 01:38:45 AM CEST
                Category: core
                Severity: 6 - Security
                 Release: 0.8.10
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Downstream bug is
https://bugzilla.redhat.com/show_bug.cgi?id=827313&list_id=730634 .

Please see the attached backtrace there. I thought it was a rather curious
stacktrace, and after a rather long search I formed a theory that the wrong
buffer size was being passed into libjpeg because of this comment in the
libjpeg-turbo sources:

  /*
   * Round up the requested size to a multiple of ALIGN_SIZE so that
   * algorithms can straddle outside the proper area up to the next
   * alignment.
   */


This comment is part of the libjpeg internal allocator, whereas we allocate
our own buffer. So perhaps that's the difference. I ran a few SWFs containing
JPEGs through Valgrind/Gnash, but Valgrind did not complain at all. Then I
ran
the SWF from the downstream bug report and Valgrind exited rather indignantly
after complaining:


==15224== Thread 2:
==15224== Invalid write of size 1
==15224==    at 0x9A56228: ??? (in /usr/lib64/libjpeg.so.62.0.0)
==15224==    by 0x9A606C7: ??? (in /usr/lib64/libjpeg.so.62.0.0)
==15224==    by 0x9A59617: ??? (in /usr/lib64/libjpeg.so.62.0.0)
==15224==    by 0x9A541FF: jpeg_read_scanlines (in
/usr/lib64/libjpeg.so.62.0.0)
==15224==    by 0x59EB78F: gnash::image::JpegInput::readScanline(unsigned
char*) (GnashImageJpeg.cpp:409)
==15224==    by 0x59E8B77:
gnash::image::Input::readSWFJpeg3(boost::shared_ptr<gnash::IOChannel>)
(GnashImage.cpp:307)


Perhaps the difference stems from different image (and thus, buffer) sizes.

So my theory is that the downstream bug is caused by the buffer being too
small and some degree of good/bad fortune, and should, presumably, be fixed by
aligning the buffer size.




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37629>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]