Bluetoothd crash caused by call to adapter.discover_devices

[AidanWoolley]

On armv7, kernel 5.4.70, with bluez 5.55, 5.60 or 5.63, the following program always causes bluetoothd to crash with SIGABRT due to corrupted memory. This seems to be due to the cleanup for the device stream: if you uncomment the loop, the crash will not occur until you press ctrl-c to terminate the program.

#[tokio::main(flavor = "current_thread")]
async fn main() -> bluer::Result<()> {
    let session = bluer::Session::new().await?;
    let adapter = session.default_adapter().await?;
    println!("Discovering devices using Bluetooth adapter {}", adapter.name());
    adapter.set_powered(true).await?;

    let device_events = adapter.discover_devices().await?;
    futures::pin_mut!(device_events);
    // loop {}
    Ok(())
}

I'm posting this issue here because the equivalent commands in bluetoothctl cause no issue.

power on
scan on
scan off
exit

[AidanWoolley]

Logs from journalctl are attached:

Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:set_discovery_filter() sender :1.114
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:parse_discovery_filter_dict() filtered discovery params: transport: 7 rssi: 32767 pathloss: 32767  duplicate data: false discoverable false pattern (null)
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:set_discovery_filter() successfully pre-set filter
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:start_discovery() sender :1.114
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:update_discovery_filter()
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:discovery_filter_to_mgmt_cp()
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:trigger_start_discovery()
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:cancel_passive_scanning()
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:start_discovery_timeout()
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:start_discovery_timeout() adapter->current_discovery_filter == 1
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:start_discovery_timeout() sending MGMT_OP_START_SERVICE_DISCOVERY 127, 7, 0
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:start_discovery_complete() status 0x00
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:discovering_callback() hci0 type 7 discovering 1 method 1
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:discovery_disconnect() owner :1.114
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:stop_discovery_complete() status 0x00
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:discovery_remove() owner :1.114
Feb 23 12:05:56 test-device bluetoothd[4404]: free(): invalid next size (fast)
Feb 23 12:05:56 test-device bluetoothd[4404]: ../bluez-5.55/src/adapter.c:discovery_free() 0x16e8b50
Feb 23 12:05:56 test-device systemd[1]: bluetooth.service: Main process exited, code=killed, status=6/ABRT
Feb 23 12:05:56 test-device systemd[1]: bluetooth.service: Failed with result 'signal'.

[surban]

This is still a bluetoothd bug, since the daemon should not crash no matter what a user space process does.

I think we have seen something similar before and it was related to libdbus, so maybe it should be reported there. But difficult to say with a core dump or at least stack trace.

[AidanWoolley]

Thanks very much for the hint - I found my exact issue in bluez issue 196 which also points to DBus, so I'll see if I can find a workaround from there...