After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 102719 - [PATCH] gst_mpeg_parse_parse_packhead reads outside the buffer
[PATCH] gst_mpeg_parse_parse_packhead reads outside the buffer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other other
: Normal normal
: 0.4.0
Assigned To: Wim Taymans
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-01-07 04:52 UTC by Joshua N Pritikin
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
re-code logic to avoid reading outside the buffer (647 bytes, patch)
2003-01-07 04:53 UTC, Joshua N Pritikin
none Details | Review

Description Joshua N Pritikin 2003-01-07 04:52:37 UTC
valgrind is amazing.  three cheers for valgrind.
Comment 1 Joshua N Pritikin 2003-01-07 04:53:39 UTC
Created attachment 13394 [details] [review]
re-code logic to avoid reading outside the buffer
Comment 2 Thomas Vander Stichele 2003-01-17 15:31:19 UTC
Joshua,

Thanks for that patch.

a few remarks:

- the GUINT-macro's are very useful for endianness, so not using them
will probably cause us a lot of problems in that area.  So I think we
should keep using them.
- can you say how it can happen that the 4th byte is out of range ? I
suspect valgrind put you on the track, but did you also find out why
this could be a problem ?
- isn't there a possibility for a workaround to check this, and then
use an endian-correct way to get at the data ? An alternative might be
to allocate one byte more by default for the buffer or something.
- please don't use // :)
Comment 3 Joshua N Pritikin 2003-01-17 15:52:40 UTC
> - the GUINT-macro's are very useful for endianness, so not using them
> will probably cause us a lot of problems in that area.  So I think we
> should keep using them.

That's nonsense.  When reading single bytes then there is no such
thing as endianness.  Bytes in the stream are always ordered the same
way.  So my patch is also an optimization (unless the compiler
optimizes out the byte-swapping).

So if this is the reason you've been waiting to commit my patch ..
please commit!

>  can you say how it can happen that the 4th byte is out of range ? I
> suspect valgrind put you on the track, but did you also find out why
> this could be a problem ?

Valgrind found it.  It just happens that the 4th byte is outside the
buffer occationally when indexing (or playing, i suppose) a large
media file.  Try scanning through a VCD or DVD and you'll hit the
crash.  i don't have any deeper explanation because i don't understand
most of the MPEG parsing code.  i'm just making a technical fix.

> please don't use // 

Yah, sorry.  It's hard to break good habits.  ;-)
Comment 4 Thomas Vander Stichele 2003-01-17 16:24:51 UTC
ok, committed