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 758032 - (CVE-2015-7496) Crash when holding Escape in lock screen
(CVE-2015-7496)
Crash when holding Escape in lock screen
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
3.18.x
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2015-11-12 22:14 UTC by Christoph Reiter (lazka)
Modified: 2015-11-17 17:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
session: disconnect signals from worker proxy when conversation is freed (4.15 KB, patch)
2015-11-13 16:24 UTC, Ray Strode [halfline]
committed Details | Review
session: Cancel worker proxy async ops when freeing conversations (9.02 KB, patch)
2015-11-15 15:38 UTC, Rui Matos
committed Details | Review

Description Christoph Reiter (lazka) 2015-11-12 22:14:26 UTC
Credit to my cat for finding this..

* Running gnome session
* Press <super>+l to lock
* Press Escape and hold

Expected:

* The slider thing going up an down in an endless loop

Happing:

* After ~5 times the slider window coming and going GS crashes

using GS 3.18.1 on debian sid
Comment 1 Rui Matos 2015-11-13 14:59:23 UTC
It looks like it's actually gdm that crashes:

Program terminated with signal SIGSEGV, Segmentation fault.
  • #0 worker_on_saved_session_name_read
    at gdm-session.c line 908
  • #0 worker_on_saved_session_name_read
    at gdm-session.c line 908
  • #1 ffi_call_unix64
  • #2 ffi_call
  • #6 #7 0x0000559eafca09ac in gdm_dbus_worker_proxy_g_signal
    at gdm-session-worker-glue.c line 3414
  • #8 ffi_call_unix64
  • #9 ffi_call
  • #14 <emit signal ??? on instance 0x559eb06d2600 [GdmDBusWorkerProxy]>
    at gsignal.c line 3439
  • #15 on_signal_received
    at gdbusproxy.c line 917
  • #16 emit_signal_instance_in_idle_cb
    at gdbusconnection.c line 3701
  • #17 g_main_context_dispatch
    at gmain.c line 3154
  • #18 g_main_context_dispatch
    at gmain.c line 3769
  • #19 g_main_context_iterate
    at gmain.c line 3840
  • #20 g_main_loop_run
    at gmain.c line 4034
  • #21 main
    at main.c line 404

Comment 2 Ray Strode [halfline] 2015-11-13 16:21:44 UTC
i guess what's happening is the worker proxy isn't getting disposed when the conversation associated with it is freed (because of an outstanding reference) and so the signal handler is dispatched with an invalid conversation.
Comment 3 Ray Strode [halfline] 2015-11-13 16:24:02 UTC
Created attachment 315418 [details] [review]
session: disconnect signals from worker proxy when conversation is freed

We don't want an outstanding reference on the worker proxy to lead to
signal handlers getting dispatched after the conversation is freed.
Comment 4 Rui Matos 2015-11-15 15:38:15 UTC
Created attachment 315632 [details] [review]
session: Cancel worker proxy async ops when freeing conversations

We need to cancel ongoing async ops for worker proxies when freeing
conversations or we'll crash when the completion handler runs and we
access free'd memory.
Comment 5 Rui Matos 2015-11-15 15:40:12 UTC
Review of attachment 315418 [details] [review]:

This looks good (with the comment below addressed), but isn't enough. See the patch I just attached for a complete fix

::: daemon/gdm-session.c
@@ +1680,3 @@
         g_clear_object (&conversation->worker_manager_interface);
+
+        g_signal_handlers_disconnect_by_func (conversation->worker_proxy,

We need to check that conversation->worker_proxy isn't NULL here. I got some NULL warnings when testing this
Comment 6 Ray Strode [halfline] 2015-11-15 18:51:34 UTC
I was going to say we need to start handling G_IO_ERROR_CANCELLED from our callbacks if we start passing a cancellable, but we already do!
Comment 7 Ray Strode [halfline] 2015-11-15 19:11:28 UTC
This is already open in public bugzilla so no point going for
an embargo.  Pushing:

Attachment 315418 [details] pushed as 5ac2246 - session: disconnect signals from worker proxy when conversation is freed
Attachment 315632 [details] pushed as 05e5fc2 - session: Cancel worker proxy async ops when freeing conversations

We should try to get a CVE assigned though.
Comment 8 Ray Strode [halfline] 2015-11-15 19:14:42 UTC
Kurt, Tomas, can one of you assign a CVE for this?
Comment 9 Kurt Seifried 2015-11-17 16:40:46 UTC
This is a public issue so CVE will be assigned by Mitre, request sent:

http://www.openwall.com/lists/oss-security/2015/11/17/8
Comment 10 Javier Jardón (IRC: jjardon) 2015-11-17 17:01:36 UTC
(In reply to Ray Strode [halfline] from comment #7)
> This is already open in public bugzilla so no point going for
> an embargo.  Pushing:
> 
> Attachment 315418 [details] pushed as 5ac2246 - session: disconnect signals
> from worker proxy when conversation is freed
> Attachment 315632 [details] pushed as 05e5fc2 - session: Cancel worker proxy
> async ops when freeing conversations
> 
> We should try to get a CVE assigned though.

Hi Ray, could we have a new GDM tarball including this soonish, please?
Comment 11 Ray Strode [halfline] 2015-11-17 17:09:53 UTC
it looks like Martin Prpič assigned CVE-2015-7496 for this issue.
Comment 12 Kurt Seifried 2015-11-17 17:24:11 UTC
Ah thanks, I was on PTO for the last week and missed that email, I replied to my posting on oss-sec to ack the existing CVE.
Comment 13 Ray Strode [halfline] 2015-11-17 17:25:06 UTC
(In reply to Javier Jardón (IRC: jjardon) from comment #10)
> (In reply to Ray Strode [halfline] from comment #7)
> > This is already open in public bugzilla so no point going for
> > an embargo.  Pushing:
> > 
> > Attachment 315418 [details] pushed as 5ac2246 - session: disconnect signals
> > from worker proxy when conversation is freed
> > Attachment 315632 [details] pushed as 05e5fc2 - session: Cancel worker proxy
> > async ops when freeing conversations
> > 
> > We should try to get a CVE assigned though.
> 
> Hi Ray, could we have a new GDM tarball including this soonish, please?

3.18.2 tarball is released now. 3.19.2 unstable tarball can't easily go out until monday since it relies on releases in gnome-session / mutter and gnome-shell for other reasons.
Comment 14 Javier Jardón (IRC: jjardon) 2015-11-17 17:39:24 UTC
(In reply to Ray Strode [halfline] from comment #13)
> (In reply to Javier Jardón (IRC: jjardon) from comment #10)
> > (In reply to Ray Strode [halfline] from comment #7)
> > > This is already open in public bugzilla so no point going for
> > > an embargo.  Pushing:
> > > 
> > > Attachment 315418 [details] pushed as 5ac2246 - session: disconnect signals
> > > from worker proxy when conversation is freed
> > > Attachment 315632 [details] pushed as 05e5fc2 - session: Cancel worker proxy
> > > async ops when freeing conversations
> > > 
> > > We should try to get a CVE assigned though.
> > 
> > Hi Ray, could we have a new GDM tarball including this soonish, please?
> 
> 3.18.2 tarball is released now. 3.19.2 unstable tarball can't easily go out
> until monday since it relies on releases in gnome-session / mutter and
> gnome-shell for other reasons.

I was thinking more in a 3.18.3 tarball
Comment 15 Ray Strode [halfline] 2015-11-17 17:55:17 UTC
not sure i follow.  The fix is in the 3.18.2 tarball i released 5 seconds before posting the message saying it's released.