GNOME Bugzilla – Bug 741751
mssdemux: pass correct type through vararg function to avoid potential crash
Last modified: 2015-09-16 08:41:41 UTC
In gstmssmanifest.c, _GstMssStreamQuality::bitrate is specified as of type "guint64" but it is set incorrectly in caps structure using "G_TYPE_INT". typedef struct _GstMssStreamQuality { xmlNodePtr xmlnode; gchar *bitrate_str; guint64 bitrate; } GstMssStreamQuality; _gst_mss_stream_audio_caps_from_qualitylevel_xml (GstMssStreamQuality * q) ... if (q->bitrate) gst_structure_set (structure, "bitrate", G_TYPE_INT, q->bitrate, NULL); ...
Created attachment 293033 [details] [review] Proposed patch
Created attachment 293039 [details] [review] Proposed patch Corrected e-mail id
Thanks for the fix but it seems that faac (other element that also deals with AAC) uses bitrate as an int and not as int64. For being uniform it would be better to have the bitrate as an INT in AAC GstStructure. Did this cause any issue to you or it just draw your attention because of the type difference?
I was testing mssdemux support in gstreamer and encountered a crash because of this.
Microsoft media for Smooth Streaming used is ElephantsDreamH.264720p, which was downloaded from Microsoft's site itself. Below is command and stack trace for your reference: root@Rajat:~# gdb --args gst-launch-1.0 playbin uri=file:///media/SDK2Streams/AdaptiveStreaming/ElephantsDreamH.264720p/ElephantsDream.ismc GNU gdb (GDB) STMicroelectronics/Linux Base 7.6-49 [build Jul 2 2014] Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-cortex-linux-gnueabi". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/gst-launch-1.0...done. (gdb) r Starting program: /usr/bin/gst-launch-1.0 playbin uri=file:///media/SDK2Streams/AdaptiveStreaming/ElephantsDreamH.264720p/ElephantsDream.ismc [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Setting pipeline to PAUSED ... [New Thread 0x76965470 (LWP 3420)] Pipeline is PREROLLING ... [New Thread 0x76165470 (LWP 3421)] [New Thread 0x75648470 (LWP 3422)] (gst-launch-1.0:3417): GLib-GObject-WARNING **: ../../gobject/gtype.c:4204: type id `0' is invalid (gst-launch-1.0:3417): GLib-GObject-WARNING **: can't peek value table for type `<invalid>' which is not currently referenced Program received signal SIGSEGV, Segmentation fault.
+ Trace 234507
Thread 1989563504 (LWP 3420)
This issue looks valid. We're passing 64-bit as vararg argument, but only specify G_TYPE_INT, which means on platforms where sizeof(int) != 64 we're not reading enough bits off the stack and then everything goes wrong from there. Question is whether the fix should be: ..., "bitrate", G_TYPE_INT, (int) q->bitrate, ... or (as proposed) ..., "bitrate", G_TYPE_INT64, q->bitrate, ... Depends on who reads this later I suppose.
I agree with Tim here. We should just go and put an explicit cast to int when setting it in the structure. Rajat, can you provide a patch for that?
(In reply to comment #7) > I agree with Tim here. We should just go and put an explicit cast to int when > setting it in the structure. I mean, we need to be uniform with the other elements expect. And as far as I checked it is used as an INT > > Rajat, can you provide a patch for that?
> Rajat, can you provide a patch for that? ok, I will prepare a patch for it
Created attachment 294004 [details] [review] Proposed patch
restored the severity as set by Tim-Philipp. I had reset it mistakenly.
Thanks for the bug report and the patch. Pushed to master: commit de246c6741d70077a06ea223297c5ebc57ba471c Author: Rajat Verma <rajat.verma@st.com> Date: Wed Jan 7 11:31:30 2015 +0530 mssdemux: fix crash while setting bitrate in caps structure q->bitrate is a guint64, but G_TYPE_INT may read fewer bits off the stack, and if we pass more then the NULL sentinel may not be found at the right place, which in turn might lead to crashes. https://bugzilla.gnome.org/show_bug.cgi?id=741751
*** Bug 755033 has been marked as a duplicate of this bug. ***