bluez5: cancel RegisterApplication calls when adapter goes away

If an adapter's removal is processed before the pending `RegisterApplication()`
dbus calls return, then those pending calls are not cancelled, and when the
(error) replies arrive, the callbacks will run into use-after-free issues
since they reference the removed adapter.

See #5096
This commit is contained in:
Barnabás Pőcze 2026-05-04 18:51:24 +02:00 committed by Wim Taymans
parent 97c8a0a5ae
commit ddab12a5aa
2 changed files with 71 additions and 29 deletions

View file

@ -350,6 +350,12 @@ struct spa_bt_monitor;
struct spa_bt_backend;
struct spa_bt_player;
enum bluez_app_id {
BLUEZ_APP_A2DP,
BLUEZ_APP_BAP,
BLUEZ_APP_LAST
};
struct spa_bt_adapter {
struct spa_list link;
struct spa_bt_monitor *monitor;
@ -366,10 +372,14 @@ struct spa_bt_adapter {
uint32_t bluetooth_class;
uint32_t profiles;
int powered;
struct bluez_app {
DBusPendingCall *register_call;
bool registered;
} apps[BLUEZ_APP_LAST];
unsigned int has_msbc:1;
unsigned int msbc_probed:1;
unsigned int a2dp_application_registered:1;
unsigned int bap_application_registered:1;
unsigned int player_registered:1;
unsigned int has_battery_provider:1;
unsigned int battery_provider_unavailable:1;