Segmentation fault when dbus.secrets service is used from docker

[thePanz]

Overview

Under linux I enabled the dbus.secret-service integration

I run: docker login registry.my.server.org, and docker is configured to use the dbus.secret-service to store credentials

1. I provide the login credentials
2. a token is stored in KeepassXC

During docker pull, the docker registry is accessed and the credentials asked from KeepassXC dbus.secret-service:

1. the dialog to allow the secret service to access the aforementioned credentials is shown
2. a copy of the same dialog is shown under the first one (asking for the same question)
3. clicking on "Allow" on the first dialog, closes the dialog
4. clicking on "Allow" on the second dialog, KeepassXC is terminated and closed
5. the original command docker pull is left running but with no progress.

Steps to Reproduce

Did not try to reproduce it without the above description

Expected Behavior

After clicking on "Allow", KeepassXC is killed, see segmentation fault log below

Actual Behavior

The first dialog to grant access appears, I click "remember" and the button "Allow"
A second dialog appears, with the same request as before. Clicking "Allow" the window disappear and KeepassXC is killed

Context

From journalctl:

Mar 30 09:58:36 xps13 kernel: keepassxc[9856]: segfault at 10 ip 00005576e6203ed7 sp 00007ffd14d541e0 error 4 in keepassxc[5576e5fc1000+2a2000]
Mar 30 09:58:36 xps13 kernel: Code: 83 2c 24 01 0f 84 85 00 00 00 48 8b 55 00 48 63 4c 24 14 48 63 42 08 48 01 c8 48 8d 6c c2 10 bf 08 00 00 00 ff 15 b1 c1 30 00 <48> 8b 0b 48 89 08 8b 11 83 c2 01 83 fa 01 0f 87 c5 00 00 00 48 89
Mar 30 09:58:36 xps13 kernel: audit: type=1701 audit(1648627116.727:405): auid=1000 uid=1000 gid=100 ses=2 pid=9856 comm="keepassxc" exe="/usr/bin/keepassxc" sig=11 res=1
Mar 30 09:58:36 xps13 systemd[527]: app-org.keepassxc.KeePassXC-830a5580f32c40d48e3e836330154c85.scope: Consumed 12.881s CPU time.

KeePassXC - Version 2.7.0
Revision: d7a9ef4

Note: I have the same issue with v2.6.6

Operating System: Linux (ArchLinux)
Desktop Env: KDE
Windowing System: X11

[bionade24]

This bug seems to happen with with more than just the docker cli accessing dbus. I can confirm the problem happening with QtKeychain, too. So I guess it's a general problem.

[bionade24]

I'm working on fixing this, though this seems super weird to me as QPointer crashes when checking if the wrapped pointer is a 0pointer.

Backtrace:

[New Thread 0x7fffe3fff640 (LWP 30123)]
YubiKey: Failed to establish PCSC context.
YubiKey: PCSC interface is disabled or not initialized.
[New Thread 0x7fffdb21b640 (LWP 30124)]
[New Thread 0x7fffdaa1a640 (LWP 30125)]
[New Thread 0x7fffda219640 (LWP 30126)]
[New Thread 0x7fffd9a18640 (LWP 30127)]
[New Thread 0x7fffd9217640 (LWP 30128)]
[New Thread 0x7fffd8a16640 (LWP 30129)]
[New Thread 0x7fffc3fff640 (LWP 30130)]
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
[New Thread 0x7fffc13eb640 (LWP 30133)]

Thread 1 "keepassxc" received signal SIGSEGV, Segmentation fault.
0x00005555555eb8fe in QWeakPointer<QObject>::internalData (this=0x28) at /usr/include/qt/QtCore/qsharedpointer_impl.h:698
698             return d == nullptr || d->strongref.loadRelaxed() == 0 ? nullptr : value;
(gdb) bt
#0  0x00005555555eb8fe in QWeakPointer<QObject>::internalData (this=0x28) at /usr/include/qt/QtCore/qsharedpointer_impl.h:698
#1  0x00005555556c77a8 in QPointer<Entry>::data (this=0x28) at /usr/include/qt/QtCore/qpointer.h:77
#2  0x00005555556c5eea in QPointer<Entry>::operator Entry* (this=0x28) at /usr/include/qt/QtCore/qpointer.h:83
#3  0x00005555558ddb6b in FdoSecrets::Item::ensureBackend (this=0x0) at /home/oskar/workspace/keepassxc/src/fdosecrets/objects/Item.cpp:341
#4  0x00005555558dbf49 in FdoSecrets::Item::locked (this=0x0, client=..., locked=@0x7fffffffd437: true) at /home/oskar/workspace/keepassxc/src/fdosecrets/objects/Item.cpp:81
#5  0x00005555558c78c3 in FdoSecrets::Service::searchItems (this=0x5555563ed9a0, client=..., attributes=..., unlocked=..., locked=...)
    at /home/oskar/workspace/keepassxc/src/fdosecrets/objects/Service.cpp:262
#6  0x00005555558964b4 in FdoSecrets::Service::qt_static_metacall (_o=0x5555563ed9a0, _c=QMetaObject::InvokeMetaMethod, _id=18, _a=0x7fffffffd610)
    at /home/oskar/workspace/keepassxc/build/src/fdosecrets/fdosecrets_autogen/64PJ3GCGVF/moc_Service.cpp:243
#7  0x0000555555896ad0 in FdoSecrets::Service::qt_metacall (this=0x5555563ed9a0, _c=QMetaObject::InvokeMetaMethod, _id=18, _a=0x7fffffffd610)
    at /home/oskar/workspace/keepassxc/build/src/fdosecrets/fdosecrets_autogen/64PJ3GCGVF/moc_Service.cpp:340
#8  0x00005555558c1b84 in FdoSecrets::DBusMgr::deliverMethod (client=..., obj=0x5555563ed9a0, method=..., args=..., ret=..., outputArgs=...)
    at /home/oskar/workspace/keepassxc/src/fdosecrets/dbus/DBusDispatch.cpp:365
#9  0x00005555558c0f8a in FdoSecrets::DBusMgr::activateObject (this=0x5555563e7530, client=..., path=..., req=..., msg=...) at /home/oskar/workspace/keepassxc/src/fdosecrets/dbus/DBusDispatch.cpp:282
#10 0x00005555558c0148 in FdoSecrets::DBusMgr::handleMessage (this=0x5555563e7530, message=...) at /home/oskar/workspace/keepassxc/src/fdosecrets/dbus/DBusDispatch.cpp:197
#11 0x00007ffff7114a18 in ?? () from /usr/lib/libQt5DBus.so.5
#12 0x00007ffff7114e4c in ?? () from /usr/lib/libQt5DBus.so.5
#13 0x00007ffff680d7d6 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#14 0x00007ffff782d1c6 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#15 0x00007ffff67e95aa in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#16 0x00007ffff67ea0a9 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#17 0x00007ffff6831678 in ?? () from /usr/lib/libQt5Core.so.5
#18 0x00007ffff4efa163 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#19 0x00007ffff4f509e9 in ?? () from /usr/lib/libglib-2.0.so.0
#20 0x00007ffff4ef76c5 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#21 0x00007ffff683557a in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#22 0x00007ffff67e188b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#23 0x00007ffff67ecfd7 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#24 0x00005555555d96e5 in main (argc=1, argv=0x7fffffffe128) at /home/oskar/workspace/keepassxc/src/main.cpp:187
(gdb)

[michaelk83]

@bionade24 does this still occur with 2.7.1? There was a crash fix included with the update, not sure if it fixes your case as well.

@thePanz , you'll need to provide a stack trace for your case. Use the latest snapshot to obtain one.

[bionade24]

@michaelk83 No, it does still occur on 2.7.1 and while building from latest develop.

I think the bug has be introduced with a31c5ba

[bionade24]

@michaelk83 If you add assert(item != nullptr); after line 541 in Service.cpp, it'll trigger.

[droidmonkey]

The OP's problem was fixed with 2.7.1

[thePanz]

I can confirm that v2.7.1 does not trigger this behavior.
Thank you @bionade24 @michaelk83