[kdeconnect] [Bug 523910] New: kdeconnectd crashes (SIGABRT, glibc heap corruption) in QBluetoothSocketPrivateBluez::_q_readNotify while formatting an ECONNRESET error string

https://bugs.kde.org/show_bug.cgi?id=523910

            Bug ID: 523910
           Summary: kdeconnectd crashes (SIGABRT, glibc heap corruption)
                    in QBluetoothSocketPrivateBluez::_q_readNotify while
                    formatting an ECONNRESET error string
    Classification: Applications
           Product: kdeconnect
      Version First 26.04.3
       Reported In:
          Platform: Arch Linux
                OS: Linux
            Status: REPORTED
          Severity: crash
          Priority: NOR
         Component: desktop-application
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

NOTE: The crash analysis below (backtrace symbolication, journal correlation)
was gathered with AI assistance (Claude) driving real debugging tools on my
machine -- coredumpctl, gdb with debuginfod symbol resolution, and journalctl
-- not generated/guessed by an LLM from a description. All addresses, source
lines, and log lines are taken directly from tool output. The "working theory"
paragraph is an interpretation of that data and may be wrong; flagging it as a
theory, not a confirmed diagnosis.

STEPS TO REPRODUCE
1. Have a device paired via KDE Connect's Bluetooth backend.
2. kdeconnectd attempts to reconnect to the device over Bluetooth.
3. The remote end resets the connection (errno 104, ECONNRESET) while
kdeconnectd is reading from the Bluetooth socket (_q_readNotify,
qbluetoothsocket_bluez.cpp:351).
4. kdeconnectd crashes shortly after while formatting the resulting error
message via qt_error_string(104).

(I don't have a manual, on-demand repro -- this happened during a background
reconnect attempt.)

OBSERVED RESULT
kdeconnectd aborts with SIGABRT ("malloc(): unaligned tcache chunk detected" --
glibc's heap-corruption detector) and is restarted a few seconds later by
systemd/D-Bus activation.

EXPECTED RESULT
Failed Bluetooth connection attempts should be handled gracefully without
corrupting the heap or crashing the daemon.

SOFTWARE/OS VERSIONS
Operating System: Arch Linux (rolling), kernel 6.18.41-1-lts
KDE Plasma Version: 6.7.3
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
kdeconnect: 26.04.3-1
qt6-connectivity (Qt Bluetooth): 6.11.1-1
glibc: 2.44+r5+g7cba77790f32-1
BlueZ/bluetoothctl: 5.87
Session type: Wayland

ADDITIONAL INFORMATION

Journal log leading up to the crash:
19:33:34  kdeconnectd: No uuids found for "<redacted-remote-bt-mac>"
19:33:38  kdeconnectd: Cannot connect to profile/service.
19:33:38  kdeconnectd: Couldn't connect to bluetooth socket: "Cannot connect to
remote profile"
19:33:39  kdeconnectd: malloc(): unaligned tcache chunk detected
19:33:39  kdeconnectd: KCrash: Application 'kdeconnectd' crashing...
crashRecursionCounter = 2
19:33:39  systemd-coredump: Process 3250 (kdeconnectd) of user 1000 dumped
core.
19:33:39  systemd: dbus-:[email protected]: Main process exited,
code=dumped, status=6/ABRT

Full backtrace (symbolicated via debuginfod.archlinux.org), crashing thread:

#2  KCrash::defaultCrashHandler (sig=6) at
kcrash/kcrash-6.28.0/src/kcrash.cpp:630
#8  __GI_abort () at abort.c:77
#11 malloc_printerr (str="malloc(): unaligned tcache chunk detected") at
malloc.c:5093
#12-14 tcache_get_n / tcache_get / __libc_malloc (bytes=56) at
malloc.c:2857,2879,3112
#15-17 _nl_make_l10nflist (language="en", territory="US", codeset="UTF-8", ...)
at ../intl/l10nflist.c:242,285,285
#18 _nl_find_domain (dirname="/usr/share/locale", locale="en",
domainname="LC_MESSAGES/libc.mo", ...) at finddomain.c:144
#19 __dcigettext (msgid1="Connection reset by peer", category=5) at
dcigettext.c:610
#20 __GI___dcgettext (msgid="Connection reset by peer", category=5) at
dcgettext.c:47
#21 translate (str="Connection reset by peer") at strerror_l.c:29
#22 __GI___strerror_l (errnum=104) at strerror_l.c:70
#23 standardLibraryErrorString (errorCode=...) at
qtbase/src/corelib/kernel/qsystemerror.cpp:96
#24 qt_error_string (code=104) at
qtbase/src/corelib/kernel/qsystemerror.cpp:154
#25 QBluetoothSocketPrivateBluez::_q_readNotify (this=0x7f2d4c01ff40) at
qtconnectivity/src/bluetooth/qbluetoothsocket_bluez.cpp:351   [errsv = 104]
#26-29 QMetaObject::activate / QSocketNotifier::activated /
QSocketNotifier::event (qsocketnotifier.cpp:325)
#30-33 QApplicationPrivate::notify_helper / QCoreApplication::notifyInternal2 /
sendEvent / socketNotifierSourceDispatch
#34-37 glib main loop dispatch
#38-41 QEventDispatcherGlib::processEvents / QEventLoop::exec / QThread::exec
#42-43 QThread::run / QThreadPrivate::start

Exact trigger: QBluetoothSocketPrivateBluez::_q_readNotify()
(qbluetoothsocket_bluez.cpp:351) gets errno=104 (ECONNRESET) reading from the
Bluetooth socket, calls qt_error_string(104) to build the error message, which
goes through strerror_l() -> glibc's _nl_find_domain()/_nl_make_l10nflist()
(lazily loading/caching the en_US locale's message catalog the first time a
translated string is needed). This is where malloc() detects the corrupted
tcache chunk and aborts.

Working theory: the corruption itself almost certainly did not happen in this
call -- malloc() just caught pre-existing damage.
_nl_find_domain/_nl_make_l10nflist mutate global, largely non-atomic gettext
state (_nl_loaded_domains et al.) the first time a given locale/domain
combination is translated. kdeconnectd runs 5 threads (D-Bus, Wayland,
Bluetooth worker, etc.); if two threads hit strerror_l()/gettext concurrently
for the first time on this domain, the lazy-init path in glibc's
intl/l10nflist.c is a plausible place for a data race to corrupt heap metadata.
This would make it a glibc/Qt threading interaction bug rather than a
QtBluetooth-specific one -- QtBluetooth's only "fault" is calling
qt_error_string() from a non-main thread during socket error handling, which
surfaces the underlying race.

This is a single occurrence -- I checked ~12 days of journal history (3 boots)
and this is the only kdeconnectd crash in that window, so I don't have a
reliable repro. Filing in case the exact backtrace/pattern is recognizable to a
maintainer. Also worth noting: the actual defect may live in Qt
(qt6-connectivity's _q_readNotify calling qt_error_string off the main thread)
and/or glibc's gettext thread-safety on first use -- happy to have this
retargeted/duplicated against QTBUG or glibc's bug tracker if a maintainer
agrees.

Full symbol resolution obtained via debuginfod.archlinux.org (Arch Linux debug
info server); package build IDs match the versions listed above.

-- 
You are receiving this mail because:
You are watching all bug changes.