Branch: refs/heads/master Home: https://github.com/bluez/bluez Commit: f54299a850676d92c3dafd83e9174fcfe420ccc9 https://github.com/bluez/bluez/commit/f54299a850676d92c3dafd83e9174fcfe420ccc9 Author: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> Date: 2023-03-30 (Thu, 30 Mar 2023) Changed paths: M profiles/audio/avrcp.c Log Message: ----------- avrcp: Fix crash while handling unsupported events The following crash can be observed if the remote peer send and unsupported event: ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000148f11 at pc 0x559644552088 bp 0x7ffe28b3c7b0 sp 0x7ffe28b3c7a0 WRITE of size 1 at 0x60b000148f11 thread T0 #0 0x559644552087 in avrcp_handle_event profiles/audio/avrcp.c:3907 #1 0x559644536c22 in control_response profiles/audio/avctp.c:939 #2 0x5596445379ab in session_cb profiles/audio/avctp.c:1108 #3 0x7fbcb3e51c43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43) #4 0x7fbcb3ea66c7 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xaa6c7) #5 0x7fbcb3e512b2 in g_main_loop_run (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x552b2) #6 0x559644754ab6 in mainloop_run src/shared/mainloop-glib.c:66 #7 0x559644755606 in mainloop_run_with_signal src/shared/mainloop-notify.c:188 #8 0x5596445bb963 in main src/main.c:1289 #9 0x7fbcb3bafd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #10 0x7fbcb3bafe3f in __libc_start_main_impl ../csu/libc-start.c:392 #11 0x5596444e8224 in _start (/usr/local/libexec/bluetooth/bluetoothd+0xf0224) Commit: c4d9b99db5a6b8efb7b710818a5261634086824b https://github.com/bluez/bluez/commit/c4d9b99db5a6b8efb7b710818a5261634086824b Author: Iulia Tanasescu <iulia.tanasescu@xxxxxxx> Date: 2023-03-31 (Fri, 31 Mar 2023) Changed paths: M btio/btio.c M client/player.c M emulator/bthost.c M lib/bluetooth.h M profiles/audio/bap.c M tools/btiotest.c M tools/iso-tester.c M tools/isotest.c Log Message: ----------- Split bt_iso_qos into dedicated structures Split bt_iso_qos into dedicated unicast and broadcast structures and add additional broadcast parameters. Commit: de8e7cfce25b8d717f5ee60ee3b79d426fdcc681 https://github.com/bluez/bluez/commit/de8e7cfce25b8d717f5ee60ee3b79d426fdcc681 Author: Hans de Goede <hdegoede@xxxxxxxxxx> Date: 2023-03-31 (Fri, 31 Mar 2023) Changed paths: M src/adapter.c Log Message: ----------- adapter: Use regular discovery for filters which only have discoverable set discovery_filter_to_mgmt_cp() does not add discovery_filter.discoverable to the created mgmt_cp_start_service_discovery struct. Instead update_discovery_filter() separately checks client->discovery_filter->discoverable for all clients. This means that for discovery-filters which only have the discoverable flag set, to put the adapter in discoverable mode while discovering, the created mgmt_cp_start_service_discovery struct is empty. This empty mgmt_cp_start_service_discovery struct then gets sent to the kernel as part of a MGMT_OP_START_SERVICE_DISCOVERY msg by start_discovery_timeout(). This use of an empty filter with MGMT_OP_START_SERVICE_DISCOVERY causes some bluetooth devices to not get seen with some (most?) Broadcom bluetooth adapters. This problem has been observed with the following Broadcom models: BCM4343A0, BCM43430A1, BCM43341B0 . On these models the following 2 devices were not being discovered when starting a scan with a filter with just discoverable set in the filter (as gnome-bluetooth does): Device 09:02:01:03:0F:87 (public) Name: Bluetooth 3.0 Keyboard Alias: Bluetooth 3.0 Keyboard Class: 0x00000540 Icon: input-keyboard Paired: yes Bonded: yes Trusted: yes Blocked: no Connected: yes WakeAllowed: yes LegacyPairing: yes UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb) UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) Modalias: bluetooth:v05ACp022Cd011B Device 00:60:D1:00:00:34 (public) Name: Bluetooth Mouse Alias: Bluetooth Mouse Class: 0x00002580 Icon: input-mouse Paired: yes Bonded: yes Trusted: yes Blocked: no Connected: yes WakeAllowed: yes LegacyPairing: no UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) Modalias: usb:v0103p0204d001E Since setting the discoverable flag on a filter only is a way to automatically put the adapter in discoverable mode itself while it is discovering; and since this does not any device filtering at all; modify merge_discovery_filters() to treat discovery with such filters as regular unfiltered discovery. This results in start_discovery_timeout() starting regular discovery through a MGMT_OP_START_DISCOVERY message and this fixes these 2 example devices not getting discovered by the mentioned Broadcom BT adapter models. Link: https://gitlab.gnome.org/GNOME/gnome-bluetooth/-/merge_requests/163 Reviewed-by: Bastien Nocera <hadess@xxxxxxxxxx> Compare: https://github.com/bluez/bluez/compare/5106fe8c868d...de8e7cfce25b
