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 667313 - rtcpbuffer: prevent overflow of 16bit header length.
rtcpbuffer: prevent overflow of 16bit header length.
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal major
: 0.10.36
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-01-04 20:56 UTC by Håvard Graff (hgr)
Modified: 2012-02-02 20:53 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch (986 bytes, patch)
2012-01-04 20:56 UTC, Håvard Graff (hgr) 		committed Details | Review

Description Håvard Graff (hgr) 2012-01-04 20:56:35 UTC 
Created attachment 204631 [details] [review]
patch

RTCP header can be  (2^16 + 1) * 4 bytes long, so when validating a bogus
packet it was possible to get a 16bit overflow resulting in a length of 0.
This would put the gst_rtcp_buffer_validate_data function in a endless loop.
Comment 1 Tim-Philipp Müller 2012-01-05 11:15:56 UTC 
This patch didn't apply because your _validate() function has an extra guint32 flags argument. If this is a generally useful change, we could do this in 0.11, for what it's worth..

 commit 0febae7443b165ceaa69641e95d7069f26719e59
 Author: Pascal Buhler <pabuhler@cisco.com>
 Date:   Wed Oct 12 11:28:10 2011 +0200

    rtcpbuffer: prevent overflow of 16bit header length.
    
    RTCP header can be  (2^16 + 1) * 4 bytes long, so when validating a bogus
    packet it was possible to get a 16bit overflow resulting in a length of 0.
    This would put the gst_rtcp_buffer_validate_data function in a endless loop.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=667313
Comment 2 Vincent Penquerc'h 2012-01-31 13:38:45 UTC 
The patch was pushed, should this be closed, or are you waiting on another patch for the flags argument ?
Comment 3 Tim-Philipp Müller 2012-02-02 20:53:57 UTC 
Let's close this. The flag stuff is probably for something different, so likely belongs in a new bug.