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 723774 - Prevent use of a GSource after it’s been destroyed in the gnutls code
Prevent use of a GSource after it’s been destroyed in the gnutls code
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: network
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-02-06 15:39 UTC by Philip Withnall
Modified: 2014-02-18 15:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gnutls: Tidy up reference handling for a child GSource (1.94 KB, patch)
2014-02-06 15:39 UTC, Philip Withnall
reviewed Details | Review
gnutls: Prevent use of a destroyed GSource in a callback (1.48 KB, patch)
2014-02-06 15:39 UTC, Philip Withnall
committed Details | Review

Description Philip Withnall 2014-02-06 15:39:23 UTC
It’s possible for a GSource to be modified (have child sources added or removed) after being destroyed in an earlier user-provided callback function. See the patch descriptions for full details.
Comment 1 Philip Withnall 2014-02-06 15:39:25 UTC
Created attachment 268302 [details] [review]
gnutls: Tidy up reference handling for a child GSource

g_source_add_child_source() adds a reference to the child, so it only
complicates matters to add one ourselves, especially when the child
source should be finalised at the same time as the parent.
Comment 2 Philip Withnall 2014-02-06 15:39:29 UTC
Created attachment 268303 [details] [review]
gnutls: Prevent use of a destroyed GSource in a callback

It’s possible for the GTlsConnectionGnutlsSource to be destroyed in its
user-provided callback function. If gnutls_source_sync() is called after
this, it ends up attempting to modify the GSource after it’s been
destroyed, which is disallowed.

Bail out of gnutls_source_sync() early if the source has already been
destroyed.
Comment 3 Dan Winship 2014-02-16 15:46:34 UTC
Comment on attachment 268302 [details] [review]
gnutls: Tidy up reference handling for a child GSource

>g_source_add_child_source() adds a reference to the child, so it only
>complicates matters to add one ourselves, especially when the child
>source should be finalised at the same time as the parent.

g_source_add_child_source() adds a ref for its own purposes, but if we are going to keep a pointer to it, then we ought to keep our own ref as well, for safety. Is the current code causing some problem, or did you just find it inaesthetic?
Comment 4 Dan Winship 2014-02-16 15:47:20 UTC
Comment on attachment 268303 [details] [review]
gnutls: Prevent use of a destroyed GSource in a callback

this one is fine, though I don't think the comment is necessary; the code itself is self-documenting
Comment 5 Philip Withnall 2014-02-17 23:43:08 UTC
Comment on attachment 268303 [details] [review]
gnutls: Prevent use of a destroyed GSource in a callback

commit 2be6abe961294bfe893ea47f2b41ebb2894ca8a2
Author: Philip Withnall <philip.withnall@collabora.co.uk>
Date:   Thu Feb 6 15:32:51 2014 +0000

    gnutls: Prevent use of a destroyed GSource in a callback
    
    It’s possible for the GTlsConnectionGnutlsSource to be destroyed in its
    user-provided callback function. If gnutls_source_sync() is called after
    this, it ends up attempting to modify the GSource after it’s been
    destroyed, which is disallowed.
    
    Bail out of gnutls_source_sync() early if the source has already been
    destroyed.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=723774

 tls/gnutls/gtlsconnection-gnutls.c | 4 ++++
 1 file changed, 4 insertions(+)
Comment 6 Philip Withnall 2014-02-17 23:46:27 UTC
(In reply to comment #3)
> (From update of attachment 268302 [details] [review])
> >g_source_add_child_source() adds a reference to the child, so it only
> >complicates matters to add one ourselves, especially when the child
> >source should be finalised at the same time as the parent.
> 
> g_source_add_child_source() adds a ref for its own purposes, but if we are
> going to keep a pointer to it, then we ought to keep our own ref as well, for
> safety. Is the current code causing some problem, or did you just find it
> inaesthetic?

The current code isn’t causing a problem, but was a little harder to follow when I was debugging this (I initially thought it was a ref counting issue). Personally I think it’s clearer if the reference is held by g_source_add_child_source(), since then it’s guaranteed not to be leaked when the child is removed, but that is just aesthetics with a touch of maintainability.
Comment 7 Dan Winship 2014-02-18 15:07:12 UTC
ok, i prefer it the way it is now, so I'm going to leave it as is. Thanks for the other patch (which made it into 2.39.90)