Public bug reported:
Release: Ubuntu 26.04 (resolute)
Package: pipewire 1.6.2-1ubuntu1 (crash is in the bluez5 SPA plugin, binary
package libspa-0.2-bluetooth)
[Impact]
The bluez5 SPA plugin (libspa-0.2-bluetooth) does not cancel pending
RegisterApplication() D-Bus calls when a Bluetooth adapter is removed. When the
(error) reply later arrives, the callback dereferences the freed adapter and
builds a D-Bus method call with an invalid object path, hitting the libdbus
_dbus_check_is_valid_path assertion and aborting the host process — in practice
killing WirePlumber and dropping all Bluetooth audio.
Any event that removes/replaces the adapter while a registration is in
flight can trigger it: bluetoothd restarts, USB Bluetooth controller
resets, suspend/resume cycles. On hardware with a reset-prone controller
(Qualcomm WCN6855/QCNFA765, ThinkPad P14s Gen 5 AMD, USB id 10ab:9309)
this crashed WirePlumber up to several times per day (13 core dumps in
10 days observed).
[Crash signature]
wireplumber: spa.bluez5: RegisterApplication() failed:
org.bluez.Error.AlreadyExists
dbus[...]: arguments to dbus_message_new_method_call() were incorrect,
assertion "_dbus_check_is_valid_path (path)" failed
wireplumber.service: Main process exited, code=dumped, status=6/ABRT
Backtrace (from apport core, /usr/bin/wireplumber):
#4 __GI_abort ()
#5..6 _dbus_warn_check_failed () libdbus-1.so.3
#7 dbus_message_new_method_call () libdbus-1.so.3
#8 ?? () spa-0.2/bluez5/libspa-bluez5.so
#9 ?? () spa-0.2/bluez5/libspa-bluez5.so
#10..11 dbus_connection_dispatch () libdbus-1.so.3
[Fix]
Fixed upstream (master, not in the 1.6 stable branch as of 1.6.6):
- ddab12a5aac54016e648c45cba3cc28ba8461fa8 "bluez5: cancel RegisterApplication
calls when adapter goes away" (upstream issue pipewire#5096)
- prerequisite eec372b "bluez5: require RegisterApplication() support"
Both apply to 1.6.2 with only line offsets. Verified locally: rebuilt
1.6.2-1ubuntu1 with the two patches; the previously reliable trigger
(restarting bluetooth.service with a BT audio device connected) no longer
produces the assertion/core dump, and the process survives live adapter USB
resets.
[Test Plan]
1. Connect a Bluetooth audio device.
2. Repeatedly run: systemctl restart bluetooth (or unplug/replug a USB BT
adapter) while WirePlumber is running.
3. Unpatched: journalctl --user -u wireplumber intermittently shows the
AlreadyExists -> dbus assertion -> code=dumped chain.
4. Patched: no assertion, no core dump; media endpoints re-register cleanly.
[What could go wrong]
The change is confined to spa/plugins/bluez5 registration lifecycle: pending
D-Bus calls are tracked per adapter and cancelled on adapter removal.
Regression risk is limited to BlueZ media application registration (Bluetooth
audio endpoint setup). eec372b additionally drops a fallback for BlueZ without
RegisterApplication() support (pre-5.56); resolute ships BlueZ 5.85, so that
path is dead code on supported systems.
Expected: WirePlumber keeps running when a Bluetooth adapter disappears.
Instead: WirePlumber aborts (SIGABRT) and all Bluetooth audio drops until it is
restarted.
** Affects: pipewire (Ubuntu)
Importance: Undecided
Status: New
** Tags: resolute
** Tags added: resolute
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2160089
Title:
bluez5: WirePlumber SIGABRT (use-after-free) when BT adapter is
removed with pending RegisterApplication calls
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2160089/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
