Repository navigation
bluetoothd segfaults in media_endpoint_remove/queue_remove during A2DP transport suspend (classic BR/EDR, Samsung Soundbar B5-Series) #2616
Description
Summary
bluetoothd reliably segfaults when an A2DP transport is suspended/released during normal playback teardown against a classic BR/EDR A2DP sink (Samsung Soundbar B5-Series). Reproduced repeatedly (6+ times) across two different bluez-alsa versions acting as the client, so this is not specific to the client-side ALSA backend - the crash is entirely in bluetoothd itself.
We initially suspected this was the known media_endpoint_destroy() UAF (Red Hat Bugzilla #2467980 / fixed by commit 7482ac, shipped in Fedora's bluez-5.87-3.fc44), but our installed build (5.87+1.git8750129efca8-1.fc44, a 2026-09-09 upstream HEAD snapshot) is well past that fix and still crashes identically - so this looks like a related but distinct bug in a neighbouring code path.
Environment
- bluez:
5.87+1.git8750129efca8-1.fc44(Fedora 44 aarch64, Apple Silicon/Asahi, but nothing in the backtrace looks architecture-specific) - Client:
bluez-alsaacting as A2DP source (-p a2dp-source), tested with both v4.3.1 and v5.0.0 - identical crash in both, confirming the bug is inbluetoothd, not the client. - Sink: Samsung Soundbar B5-Series, classic BR/EDR, A2DP, SBC only.
Crash
coredumpctl shows repeated bluetoothd SIGSEGV crashes, each coinciding exactly with a playback/transport-release attempt. Symbolized backtrace (from coredumpctl's own resolution against the installed build's dynamic symbol table - full debug info with locals not yet gathered):
#0 queue_remove (bluetoothd)
#1 media_endpoint_remove (bluetoothd)
#2 a2dp_unregister_sep.lto_priv.0 (bluetoothd)
#3 transport_a2dp_suspend (bluetoothd)
#4 service_filter.lto_priv.0 (bluetoothd)
#5 message_filter.lto_priv.0 (bluetoothd)
#6 dbus_connection_dispatch (libdbus-1.so.3)
#7 message_dispatch.lto_priv.0 (bluetoothd)
#8-11 GLib main loop (g_idle_dispatch -> g_main_loop_run)
#12 main
Reproduced at least 6 times over two days with consistent timing: the crash happens on (or shortly after) the first attempt to actually use/release the A2DP transport following a connect, every time.
Steps to reproduce
bluetoothctl pair/trust/connect <soundbar MAC>- succeeds reliably, A2DP endpoint negotiates normally (confirmed viabluealsa-aplay -L: SBC, S16_LE, 2 channels, 48000 Hz).- Attempt to open/play a PCM via the negotiated A2DP source role (e.g.
aplay -D "bluealsa:DEV=<mac>,PROFILE=a2dp" some.wavagainst bluez-alsa). bluetoothdsegfaults (see backtrace above). The Bluetooth connection drops;bluetoothdis typically restarted automatically by systemd.
This happens regardless of the exact PCM format requested (tried mismatched formats, a format matching the daemon's own negotiated rate exactly via a type plug ALSA alias, and 44.1kHz forced via bluez-alsa's --a2dp-force-audio-cd) - the crash occurs once the transport-suspend/release path is actually exercised, independent of the audio format.
Why we think this is BlueZ-side, not a client bug
The exact same crash occurs identically against two different bluez-alsa releases (v4.3.1 and v5.0.0) acting as the A2DP source client - the only common factor is bluetoothd itself. coredumpctl confirms bluetoothd (not the client) is the process that actually segfaults.
Happy to gather a full backtrace with debug symbols/local variables (bluez-debuginfo etc.) if that would help narrow it down further - just let us know.
(Originally reported client-side at arkq/bluez-alsa#813 before coredumpctl showed the crash is actually in bluetoothd, not bluez-alsa.)
Activity
cgatnet commentedon Oct 1, 2026
Hardware detail, in case it's relevant: this is an Apple M2 Mac mini (not M1/M3), Bluetooth adapter
hci0using thehci_bcm4377driver (Broadcom combo chip). WiFi (brcmfmac) is on a separate kernel driver and was disabled entirely for unrelated reasons, so it shouldn't be a factor here.cgatnet commentedon Oct 1, 2026
edit: this turns out to be wrong, see next comment...
cgatnet commentedon Oct 5, 2026
Update after further testing: my earlier comment suggesting this is specific to the onboard adapter (Apple Silicon hci_bcm4377) was wrong. A follow-up production test crashed identically on a USB dongle (CSR8510 A10, different chipset/driver) under the same conditions - the "adapter-dependent" theory doesn't hold up under a cleaner comparison. Apologies for the noise.
What actually distinguishes the crashing runs from the non-crashing ones: running bluealsad under systemd supervision vs. as an unconfined, ad-hoc process (e.g. nohup bluealsad ... &). This held across a full bisection of systemd sandboxing directives (ProtectSystem, PrivateDevices, CapabilityBoundingSet, RestrictAddressFamilies, SystemCallFilter, MemoryDenyWriteExecute, etc. - none individually responsible), unit Type=simple vs Type=dbus/BusName=, and Slice=system.slice vs user.slice - every systemd-supervised variant crashed bluetoothd reliably on transport teardown, every ad-hoc-process variant didn't.
strace -f on both processes during a crash: bluealsad gets an explicit SIGTERM from PID 1 (no corresponding "Stopping ..." journal entry), with no blocked/denied syscalls beforehand (ruling out sandboxing as the direct cause). bluetoothd then segfaults in the same queue_remove/media_endpoint_remove/a2dp_unregister_sep path as before (SEGV_MAPERR, si_addr=0x31). The mechanism connecting "process is systemd-tracked" to "bluetoothd segfaults on its D-Bus disconnect" is still not understood on my end - sharing in case it's a useful data point for narrowing this down, since it suggests the trigger may be about how the D-Bus connection drops (systemd-initiated vs. a bare process death) rather than anything adapter- or hardware-specific.