https://bugs.kde.org/show_bug.cgi?id=525160
Bug ID: 525160
Summary: Bluetooth backend's RFCOMM server requests
BT_SECURITY_HIGH, breaking Bluetooth audio devices
with NoInputNoOutput IO capability
Classification: Applications
Product: kdeconnect
Version First 25.12.3
Reported In:
Platform: Kubuntu
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: common
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
SUMMARY
kdeconnectd registers a Serial Port Profile service on RFCOMM channel 1
whenever
it runs, including when no device has ever been paired over Bluetooth. The
listening socket is created with QBluetooth::Security::Secure, which Qt maps to
BT_SECURITY_HIGH, which makes the kernel demand MITM protection on any incoming
connection to that channel.
Bluetooth audio devices that probe for Serial Port during their SDP sweep will
open that channel. If such a device is NoInputNoOutput, as most earbuds are,
MITM
can never be satisfied, because NoInputNoOutput forces the Just Works
association
model, which by definition yields an unauthenticated link key. BlueZ therefore
discards the valid stored key, rejects its own pairing confirmation, and the
device drops the link.
Net effect: installing KDE Connect makes some Bluetooth headsets disconnect 4-9
seconds after every connection, with nothing pointing at KDE Connect as the
cause.
STEPS TO REPRODUCE
1. Run a Plasma session with kdeconnectd running. No paired KDE Connect device
is
needed; a fresh install with an empty ~/.config/kdeconnect reproduces it.
2. Pair Bluetooth earbuds that probe for Serial Port and present IO capability
NoInputNoOutput. Observed with Baseus Bowie MC1 Pro.
3. bluetoothctl connect <EARBUDS_MAC>
OBSERVED RESULT
The link authenticates correctly with the stored key, then dies 4-9 seconds
later
with Authentication Failure (0x05). Every time.
Killing kdeconnectd, or removing the package, fixes it completely. Verified
over a
2-minute hold with both A2DP sink and HFP microphone working, with no other
change
to the system.
EXPECTED RESULT
KDE Connect's presence should not break unrelated Bluetooth audio devices.
ROOT CAUSE
The full chain, each step verified against current source:
1. kdeconnect-kde, core/backends/bluetooth/bluetoothlinkproviderimpl.cpp:62
mBluetoothServer->setSecurityFlags(QBluetooth::Security::Encryption
| QBluetooth::Security::Secure);
2. qtconnectivity, src/bluetooth/qbluetoothserver_bluez.cpp:73-77
if (requestedSecLevel & QBluetooth::Security::Authorization)
security.level = BT_SECURITY_LOW;
if (requestedSecLevel & QBluetooth::Security::Encryption)
security.level = BT_SECURITY_MEDIUM;
if (requestedSecLevel & QBluetooth::Security::Secure)
security.level = BT_SECURITY_HIGH;
The assignments are sequential, so Secure overrides Encryption. The
Encryption
flag in step 1 has no effect; the socket ends at BT_SECURITY_HIGH.
3. linux, net/bluetooth/rfcomm/core.c, rfcomm_check_security()
switch (d->sec_level) {
case BT_SECURITY_HIGH:
case BT_SECURITY_FIPS:
auth_type = HCI_AT_GENERAL_BONDING_MITM;
break;
case BT_SECURITY_MEDIUM:
auth_type = HCI_AT_GENERAL_BONDING;
break;
...
4. linux, include/net/bluetooth/hci.h
#define HCI_AT_GENERAL_BONDING 0x04
#define HCI_AT_GENERAL_BONDING_MITM 0x05
5. Which is exactly what appears on the wire.
HCI TRACE (btmon, MAC addresses redacted)
1. Connect; Link Key Request -> Reply (stored key) -> Encryption on. OK.
2. The earbuds SDP-query Serial Port (0x1101). We answer:
Attribute: Service Class ID List (0x0001)
UUID 185f3df4-3268-4e3f-9fca-d4d5059915bd
UUID Serial Port (0x1101)
Attribute: Protocol Descriptor List (0x0004)
L2CAP (0x0100)
RFCOMM (0x0003), channel 0x01
Attribute: 0x0100
"KDE Connect"
3. The earbuds open it:
> ACL Data RX: RFCOMM: Set Async Balance Mode (SABM)
Address: 0x0b cr 1 dlci 0x02 (= server channel 1)
4. 0.05 ms later the host requests authentication and refuses its own stored
key:
< HCI Command: Authentication Requested
> HCI Event: Link Key Request
< HCI Command: Link Key Request Negative Reply
5. The IO capability reply is self-contradictory, since NoInputNoOutput cannot
perform MITM:
< HCI Command: IO Capability Request Reply
IO capability: NoInputNoOutput (0x03)
Authentication: General Bonding - MITM required (0x05)
6. BlueZ rejects its own confirmation 145 microseconds later. That is far too
fast
for a D-Bus round trip, so no pairing agent is consulted; the rejection is
internal:
> HCI Event: User Confirmation Request 19.351281
< HCI Command: User Confirmation Request Neg Reply 19.351426
> HCI Event: Simple Pairing Complete: Authentication Failure (0x05)
> HCI Event: Disconnect: Remote User Terminated Connection (0x13)
SUGGESTED FIX
Drop QBluetooth::Security::Secure from bluetoothlinkproviderimpl.cpp:62:
mBluetoothServer->setSecurityFlags(QBluetooth::Security::Encryption);
That leaves BT_SECURITY_MEDIUM -> HCI_AT_GENERAL_BONDING (0x04), which requires
encryption but not MITM, and is satisfiable by the unauthenticated key a Just
Works pairing produces. I may be wrong about the security implications for KDE
Connect itself, so please judge that part; my reading is that RFCOMM-level MITM
is
not what protects the link, but I have not studied the protocol above the
socket.
Worth considering independently: do not register the SPP record at all when no
device is paired over Bluetooth. Most affected users have never used KDE
Connect
over Bluetooth, so that would remove the exposure entirely for them.
A user-facing switch to disable the Bluetooth backend would also help. Today
the
only reliable remedy is uninstalling the package, because disabling autostart
is
not enough: D-Bus activation still launches kdeconnectd.
SOFTWARE/OS VERSIONS
kdeconnect 25.12.3-0ubuntu1
bluez 5.85-4ubuntu0.1
kernel 7.0.0-30-generic
Plasma 6.6 (Wayland)
distro Kubuntu 26.04
adapter Intel AX201 (8087:0026)
device Baseus Bowie MC1 Pro (A2DP Sink + AVRCP + HFP + Serial Port)
POSSIBLY RELATED
https://github.com/CachyOS/distribution/issues/361 reports the same symptom on
a
default Plasma install, with two workarounds: uninstall KDE Connect, or
downgrade
bluez to 5.82 or earlier. I have not tested the bluez downgrade and cannot
confirm
that version boundary. That report contains no mechanism or trace.
I have a full btmon capture (MACs and link key redacted) and can attach it.
--
You are receiving this mail because:
You are watching all bug changes.
