GNOME Bugzilla – Bug 765146
[Regression] Crashes on LUKS/dm-crypt mount
Last modified: 2016-04-18 14:38:45 UTC
When mounting LUKS/dm-crupt volume with Nautilus, gvfs very often crashes since beea21e124d95c2f7cc0130148084e5e86eb46e5 is the first bad commit commit beea21e124d95c2f7cc0130148084e5e86eb46e5 Author: Ondrej Holy <oholy@redhat.com> Date: Thu Mar 24 12:07:43 2016 +0100 udisks2: Abort mount operation if volume is unlocked Mount operation for encrypted volumes consists from two udisks2 calls (unlock and mount). Volume monitor is able to mount already unlocked volumes. However password prompt doesn't disappear if the volume is unlocked externally and any reaction causes mount operation failure. The volume may be unlocked externally by e.g. project Tang, see https://github.com/latchset/tang for more details. Abort mount operation and continue with mounting in such situations. https://bugzilla.gnome.org/show_bug.cgi?id=763890 ---- kernel: traps: gvfs-udisks2-vo[695] general protection ip:7fad3c94f914 sp:7ffea4ce6820 error:0 in libgobject-2.0.so.0.4800.0[7fad3c91b000+51000] systemd[1]: Created slice system-systemd\x2dcoredump.slice. systemd[1]: Started Process Core Dump (PID 1014/UID 0). systemd[556]: gvfs-udisks2-volume-monitor.service: Main process exited, code=dumped, status=11/SEGV systemd[556]: gvfs-udisks2-volume-monitor.service: Unit entered failed state. systemd[556]: gvfs-udisks2-volume-monitor.service: Failed with result 'core-dump'. org.gnome.Shell.desktop[614]: (gnome-shell:614): GVFS-RemoteVolumeMonitor-WARNING **: Owner of volume monitor org.gtk.vfs.UDisks2VolumeMonitor disconnected from the bus; removing drives/volumes/mounts systemd-coredump[1015]: Process 695 (gvfs-udisks2-vo) of user 1001 dumped core. Stack trace of thread 695: #0 0x00007fad3c94f914 g_type_check_instance_cast (libgobject-2.0.so.0) #1 0x00000000004134e3 on_udisks_client_changed (gvfs-udisks2-volume-monitor) #2 0x00007fad39d601f0 ffi_call_unix64 (libffi.so.6) #3 0x00007fad39d5fc58 ffi_call (libffi.so.6) #4 0x00007fad3c92b7c9 g_cclosure_marshal_generic (libgobject-2.0.so.0) #5 0x00007fad3c92afa5 g_closure_invoke (libgobject-2.0.so.0) #6 0x00007fad3c93cff1 n/a (libgobject-2.0.so.0) #7 0x00007fad3c945d8c g_signal_emit_valist (libgobject-2.0.so.0) #8 0x00007fad3c9460bf g_signal_emit (libgobject-2.0.so.0) #9 0x00007fad3d5d711e n/a (libudisks2.so.0) #10 0x00007fad3c655823 n/a (libglib-2.0.so.0) #11 0x00007fad3c654dba g_main_context_dispatch (libglib-2.0.so.0) #12 0x00007fad3c655160 n/a (libglib-2.0.so.0) #13 0x00007fad3c655482 g_main_loop_run (libglib-2.0.so.0) #14 0x000000000041edeb g_vfs_proxy_volume_monitor_daemon_main (gvfs-udisks2-volume-monitor) #15 0x00007fad3c06d710 __libc_start_main (libc.so.6) #16 0x000000000040a699 _start (gvfs-udisks2-volume-monitor) Stack trace of thread 696: #0 0x00007fad3c12bc3d poll (libc.so.6) #1 0x00007fad3c6550fc n/a (libglib-2.0.so.0) #2 0x00007fad3c65520c g_main_context_iteration (libglib-2.0.so.0) #3 0x00007fad3c655249 n/a (libglib-2.0.so.0) #4 0x00007fad3c67b975 n/a (libglib-2.0.so.0) #5 0x00007fad3c3f5424 start_thread (libpthread.so.0) #6 0x00007fad3c134cbd __clone (libc.so.6) Stack trace of thread 980: #0 0x00007fad3c1307f9 syscall (libc.so.6) #1 0x00007fad3c699afa g_cond_wait_until (libglib-2.0.so.0) #2 0x00007fad3c629929 n/a (libglib-2.0.so.0) #3 0x00007fad3c67c2e6 n/a (libglib-2.0.so.0) #4 0x00007fad3c67b975 n/a (libglib-2.0.so.0) #5 0x00007fad3c3f5424 start_thread (libpthread.so.0) #6 0x00007fad3c134cbd __clone (libc.so.6) Stack trace of thread 697: #0 0x00007fad3c12bc3d poll (libc.so.6) #1 0x00007fad3c6550fc n/a (libglib-2.0.so.0) #2 0x00007fad3c655482 g_main_loop_run (libglib-2.0.so.0) #3 0x00007fad3cc516d6 n/a (libgio-2.0.so.0) #4 0x00007fad3c67b975 n/a (libglib-2.0.so.0) #5 0x00007fad3c3f5424 start_thread (libpthread.so.0) #6 0x00007fad3c134cbd __clone (libc.so.6) Stack trace of thread 1012: #0 0x00007fad3c1307f9 syscall (libc.so.6) #1 0x00007fad3c699afa g_cond_wait_until (libglib-2.0.so.0) #2 0x00007fad3c629929 n/a (libglib-2.0.so.0) #3 0x00007fad3c67c2e6 n/a (libglib-2.0.so.0) #4 0x00007fad3c67b975 n/a (libglib-2.0.so.0) #5 0x00007fad3c3f5424 start_thread (libpthread.so.0) #6 0x00007fad3c134cbd __clone (libc.so.6) Stack trace of thread 1013: #0 0x00007fad3c1307f9 syscall (libc.so.6) #1 0x00007fad3c699afa g_cond_wait_until (libglib-2.0.so.0) #2 0x00007fad3c629929 n/a (libglib-2.0.so.0) #3 0x00007fad3c67c2e6 n/a (libglib-2.0.so.0) #4 0x00007fad3c67b975 n/a (libglib-2.0.so.0) #5 0x00007fad3c3f5424 start_thread (libpthread.so.0) #6 0x00007fad3c134cbd __clone (libc.so.6)
Thanks for taking the time to report this. I tested the mentioned commit in various cases before pushing and I never saw any crashes. Could you please provide more info, when the crash happens and how the crash may be reproduced? Does it crash immediately after you type a password and press Unlock?
Actually I do not see any crashes, however valgrind reports invalid read after unlocking: ==2398== Invalid read of size 8 ==2398== at 0x411183: on_udisks_client_changed (gvfsudisks2volume.c:615) ==2398== by 0x8FBFD2F: ffi_call_unix64 (unix64.S:76) ==2398== by 0x8FBF79A: ffi_call (ffi64.c:525) ==2398== by 0x5F1FFC8: g_cclosure_marshal_generic (gclosure.c:1487) ==2398== by 0x5F1F7A4: g_closure_invoke (gclosure.c:801) ==2398== by 0x5F31850: signal_emit_unlocked_R (gsignal.c:3627) ==2398== by 0x5F3A52F: g_signal_emit_valist (gsignal.c:3383) ==2398== by 0x5F3A8FE: g_signal_emit (gsignal.c:3439) ==2398== by 0x4E7B51D: ??? (in /usr/lib64/libudisks2.so.0.0.0) ==2398== by 0x61AC892: g_timeout_dispatch (gmain.c:4577) ==2398== by 0x61ABE39: g_main_dispatch (gmain.c:3154) ==2398== by 0x61ABE39: g_main_context_dispatch (gmain.c:3769) ==2398== by 0x61AC1CF: g_main_context_iterate.isra.29 (gmain.c:3840) ==2398== Address 0xa23f360 is 32 bytes inside a block of size 112 free'd ==2398== at 0x4C29CF0: free (vg_replace_malloc.c:530) ==2398== by 0x61B15ED: g_free (gmem.c:189) ==2398== by 0x411D4E: mount_data_free (gvfsudisks2volume.c:956) ==2398== by 0x412059: mount_cb (gvfsudisks2volume.c:1071) ==2398== by 0x5C155A2: g_task_return_now (gtask.c:1106) ==2398== by 0x5C15C4D: g_task_return (gtask.c:1164) ==2398== by 0x5C6DB2A: reply_cb (gdbusproxy.c:2579) ==2398== by 0x5C155A2: g_task_return_now (gtask.c:1106) ==2398== by 0x5C15C4D: g_task_return (gtask.c:1164) ==2398== by 0x5C62659: g_dbus_connection_call_done (gdbusconnection.c:5704) ==2398== by 0x5C155A2: g_task_return_now (gtask.c:1106) ==2398== by 0x5C155D8: complete_in_idle_cb (gtask.c:1120) ==2398== Block was alloc'd at ==2398== at 0x4C2A988: calloc (vg_replace_malloc.c:711) ==2398== by 0x61B1530: g_malloc0 (gmem.c:124) ==2398== by 0x412CCD: gvfs_udisks2_volume_mount (gvfsudisks2volume.c:1531) ==2398== by 0x41C283: handle_volume_mount (gvfsproxyvolumemonitordaemon.c:1240) ==2398== by 0x8FBFD2F: ffi_call_unix64 (unix64.S:76) ==2398== by 0x8FBF79A: ffi_call (ffi64.c:525) ==2398== by 0x5F1FFC8: g_cclosure_marshal_generic (gclosure.c:1487) ==2398== by 0x5F1F7A4: g_closure_invoke (gclosure.c:801) ==2398== by 0x5F31850: signal_emit_unlocked_R (gsignal.c:3627) ==2398== by 0x5F39650: g_signal_emitv (gsignal.c:3122) ==2398== by 0x421428: _gvfs_remote_volume_monitor_skeleton_handle_method_call (gvfsvolumemonitordbus.c:4588) ==2398== by 0x5C78BB0: g_dbus_interface_method_dispatch_helper (gdbusinterfaceskeleton.c:609) ==2398== by 0x5C78BB0: skeleton_intercept_handle_method_call (gdbusinterfaceskeleton.c:650) I am going to investigate why...
Created attachment 326241 [details] [review] udisks2: Fix crash when mounting encrypted volume Code handling external unlocks during mount operation was added by the commit beea21e recently. Unfortunately, it may cause crashes due to accessing already freed memory, because gvfs_udisks2_volume_monitor_update waits for pending dbus messages using udisks_client_settle, thus another main context iteration may happen (i.e. mount operation may finish and mount data may be freed) before accessing mount data pointer. The mount data pointer has to be obtained after gvfs_udisks2_volume_monitor_update call in order to fix this crashes.
So I proposed fix for this bug. Can you please test this patch whether it fixes the crashes for you? I can create scratch build for Fedora if you want....
Darn, that was fast :) This patch fixes the issue for me. Thank you very much!
Thanks for testing! Please do not change the status of the bug yourself. The bug status should be modified only by developers in most cases. The patch hasn't been pushed to master, so it is not fixed yet...
Comment on attachment 326241 [details] [review] udisks2: Fix crash when mounting encrypted volume Pushed to master (commit fd36dd9e) and gnome-3-20 (commit 874a5173).