[Top][All Lists]
[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/
- [Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3,
Bastiaan Jacques <=
- [Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3, Rob Savoye, 2012/10/24
- [Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3, Bastiaan Jacques, 2012/10/25
- [Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3, Bastiaan Jacques, 2012/10/25
- [Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3, Rob Savoye, 2012/10/25
- [Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3, Bastiaan Jacques, 2012/10/25
- [Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3, Rob Savoye, 2012/10/25
- [Gnash-commit] [bug #37629] buffer overflow from Input::readSWFJpeg3, Bastiaan Jacques, 2012/10/28