Code: gsm_xsmp_client_disconnect (GsmXSMPClient *client)
{
        if (client->priv->watch_id > 0) {
                g_source_remove (client->priv->watch_id);
        }

        if (client->priv->conn != NULL) {
                SmsCleanUp (client->priv->conn);
        }

        if (client->priv->ice_connection != NULL) {
                 IceSetShutdownNegotiation (client->priv->ice_connection, FALSE);
                 IceCloseConnection (client->priv->ice_connection);
         }
        if (client->priv->protocol_timeout > 0) {
                g_source_remove (client->priv->protocol_timeout);
        }
 }

Vulnerability Type: 
CWE ID: CWE-835
Summary: Bad reference counting in the context of accept_ice_connection() in gsm-xsmp-server.c in old versions of gnome-session up until version 2.29.92 allows a local attacker to establish ICE connections to gnome-session with invalid authentication data (an invalid magic cookie). Each failed authentication attempt will leak a file descriptor in gnome-session. When the maximum number of file descriptors is exhausted in the gnome-session process, it will enter an infinite loop trying to communicate without success, consuming 100% of the CPU. The graphical session associated with the gnome-session process will stop working correctly, because communication with gnome-session is no longer possible.
Commit Message: [gsm] Delay the creation of the GsmXSMPClient until it really exists

We used to create the GsmXSMPClient before the XSMP connection is really
accepted. This can lead to some issues, though. An example is:
https://bugzilla.gnome.org/show_bug.cgi?id=598211#c19. Quoting:

 "What is happening is that a new client (probably metacity in your
 case) is opening an ICE connection in the GSM_MANAGER_PHASE_END_SESSION
 phase, which causes a new GsmXSMPClient to be added to the client
 store. The GSM_MANAGER_PHASE_EXIT phase then begins before the client
 has had a chance to establish a xsmp connection, which means that
 client->priv->conn will not be initialized at the point that xsmp_stop
 is called on the new unregistered client."

The fix is to create the GsmXSMPClient object when there's a real XSMP
connection. This implies moving the timeout that makes sure we don't
have an empty client to the XSMP server.

https://bugzilla.gnome.org/show_bug.cgi?id=598211