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 782648 - heap-use-after-free in gst_debug_print_object() spotted by Asan
heap-use-after-free in gst_debug_print_object() spotted by Asan
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-05-15 08:36 UTC by Fabrice Bellet
Modified: 2018-11-03 12:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
heap-use-after-free in gstvalue.c (27.76 KB, text/plain)
2017-05-15 08:36 UTC, Fabrice Bellet
  Details
heap-use-after-free in gsttask.c (13.72 KB, text/plain)
2017-05-15 08:37 UTC, Fabrice Bellet
  Details
gstvalue: fix a race when retrieving object name (868 bytes, patch)
2017-05-15 08:40 UTC, Fabrice Bellet
reviewed Details | Review
gsttask: object debug function should lock the object first (1.03 KB, patch)
2017-05-15 08:42 UTC, Fabrice Bellet
reviewed Details | Review
object: Warn if setting the object name if reference count is greater than 1 (1.47 KB, patch)
2017-05-15 10:08 UTC, Sebastian Dröge (slomo)
rejected Details | Review

Description Fabrice Bellet 2017-05-15 08:36:18 UTC
Created attachment 351856 [details]
heap-use-after-free in gstvalue.c

Hi,

Asan found a couple of use after free cases when we print an object name, mainly when debugging level is high enough. There's a possibility that the name is read after the old pointer is freed and before the new one is assigned in gst_object_set_name().
Comment 1 Fabrice Bellet 2017-05-15 08:37:42 UTC
Created attachment 351858 [details]
heap-use-after-free in gsttask.c
Comment 2 Fabrice Bellet 2017-05-15 08:40:55 UTC
Created attachment 351859 [details] [review]
gstvalue: fix a race when retrieving object name

Possible fix for the access to the object's name in gstvalue
Comment 3 Fabrice Bellet 2017-05-15 08:42:16 UTC
Created attachment 351860 [details] [review]
gsttask: object debug function should lock the object first

Possible fix for the access to the object's name in gsttask.
Comment 4 Sebastian Dröge (slomo) 2017-05-15 09:40:27 UTC
Review of attachment 351860 [details] [review]:

::: gst/gsttask.c
@@ +689,1 @@
   GST_DEBUG_OBJECT (task, "Changing task %p to state %d", task, state);

Where is this printing the name of the object?
Comment 5 Sebastian Dröge (slomo) 2017-05-15 09:53:39 UTC
Review of attachment 351859 [details] [review]:

::: gst/gstvalue.c
@@ +6436,3 @@
         g_strdup_printf ("(%s) %s", G_OBJECT_TYPE_NAME (obj),
         GST_OBJECT_NAME (obj));
+    GST_OBJECT_UNLOCK (obj);

This should not be needed as the object name is considered immutable. As long as you have a reference to the object, it's not going to go away
Comment 6 Sebastian Dröge (slomo) 2017-05-15 10:08:37 UTC
Created attachment 351877 [details] [review]
object: Warn if setting the object name if reference count is greater than 1

Various places in the code are accessing the object name without any
locks and assume that it never changes once set and is valid as long as
the object reference is.
Comment 7 Tim-Philipp Müller 2017-05-15 10:14:58 UTC
Comment on attachment 351877 [details] [review]
object: Warn if setting the object name if reference count is greater than 1

>+  if (GST_OBJECT_REFCOUNT (object) > 1) {
>+    g_warning
>+        ("Trying to set name on GstObject with reference count greater than 1");
>+  }

Should maybe be GST_OBJECT_REFCOUNT_VALUE, so we do an atomic int get, otherwise asan will probably complain again ;)
Comment 8 Sebastian Dröge (slomo) 2017-05-15 10:19:17 UTC
Also it does not work because setting the name via property already increases the refcount :) Lots of tests are failing.
Comment 9 Sebastian Dröge (slomo) 2017-05-15 13:12:03 UTC
Not sure what else we can do here
Comment 10 Mathieu Duponchelle 2017-11-02 22:35:54 UTC
(In reply to Sebastian Dröge (slomo) from comment #9)
> Not sure what else we can do here

Maybe have a "set_name_unchecked" function, called from both gst_object_set_name and gst_object_set_property, in gst_object_set_name check if refcount > 1 and in set_property if refcount > 2?

That's pretty clunky but the best I can think of
Comment 11 GStreamer system administrator 2018-11-03 12:41:12 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/236.