media: fix crash when clearing BAP transport

Several types of use-after-free crashes can be found by making BAP sound
server delay its SetConfiguration response (eg. debugger breakpoint),
and disconnecting the device while bluetoothd waits for SetConfiguration
response.

One of these occurs in media.c:pac_clear

==5070==ERROR: AddressSanitizer: heap-use-after-free on address XXXX
READ of size 3 at 0x606000031640 thread T0
...
    bluez#4 0x559891 in btd_debug src/log.c:117
    bluez#5 0x46abfd in pac_clear profiles/audio/media.c:1096
    bluez#6 0x79fcaf in bap_stream_clear_cfm src/shared/bap.c:914
    bluez#7 0x7a060d in bap_stream_detach src/shared/bap.c:987
    bluez#8 0x7a25ea in bap_stream_state_changed src/shared/bap.c:1210
    bluez#9 0x7a29cd in stream_set_state src/shared/bap.c:1254
    bluez#10 0x7be824 in stream_foreach_detach src/shared/bap.c:3820
    bluez#11 0x71d15d in queue_foreach src/shared/queue.c:207
    bluez#12 0x7beb98 in bt_bap_detach src/shared/bap.c:3836
    bluez#13 0x5228cb in bap_disconnect profiles/audio/bap.c:1342
    bluez#14 0x63247c in btd_service_disconnect src/service.c:305
...

which crashes trying to address the path string stored in bt_bap_stream
user data, which has been freed eg. via

freed by thread T0 here:
    #0 0x7f16708b9388 in __interceptor_free.part.0 (/lib64/libasan.so.8+0xb9388)
    bluez#1 0x7f167071b8cc in g_free (/lib64/libglib-2.0.so.0+0x5b8cc)
    bluez#2 0x7047b7 in remove_interface gdbus/object.c:660
    bluez#3 0x70aef6 in g_dbus_unregister_interface gdbus/object.c:1394
    bluez#4 0x47be30 in media_transport_destroy profiles/audio/transport.c:217
    bluez#5 0x464ab9 in endpoint_remove_transport profiles/audio/media.c:270
    bluez#6 0x464d26 in clear_configuration profiles/audio/media.c:292
    bluez#7 0x464e69 in clear_endpoint profiles/audio/media.c:300
    bluez#8 0x46516e in endpoint_reply profiles/audio/media.c:325
...

or

freed by thread T0 here:
    #0 0x7ff2b2ab9388 in __interceptor_free.part.0 (/lib64/libasan.so.8+0xb9388)
    bluez#1 0x51b1fe in ep_free profiles/audio/bap.c:513
    bluez#2 0x704cfa in remove_interface gdbus/object.c:660
    bluez#3 0x70b439 in g_dbus_unregister_interface gdbus/object.c:1394
    bluez#4 0x516d6d in ep_unregister profiles/audio/bap.c:102
    bluez#5 0x522bd1 in ep_remove profiles/audio/bap.c:1352
    bluez#6 0x71e06a in queue_remove_if src/shared/queue.c:279
    bluez#7 0x71e69e in queue_remove_all src/shared/queue.c:321
    bluez#8 0x522d00 in bap_disconnect profiles/audio/bap.c:1362
...

The cause is that the path string is owned either by media transports or
media endpoints, and their lifetime does not necessarily match that of
the BAP stream, so that the user data may already be freed when
pac_clear is entered.

Fix the crash in pac_clear by matching the transports by their stream
pointer, not using the potentially invalid user data, following the
unmerged v3 version of the problematic patch.

Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")

profiles/audio/media.c

@@ -1086,19 +1086,20 @@ static int pac_config(struct bt_bap_stream *stream, struct iovec *cfg,
 static void pac_clear(struct bt_bap_stream *stream, void *user_data)
 {
 	struct media_endpoint *endpoint = user_data;
-	struct media_transport *transport;
-	const char *path;
+	GSList *item;
 
-	path = bt_bap_stream_get_user_data(stream);
-	if (!path)
-		return;
+	DBG("endpoint %p stream %p", endpoint, stream);
 
-	DBG("endpoint %p path %s", endpoint, path);
+	item = endpoint->transports;
+	while (item) {
+		struct media_transport *transport = item->data;
 
-	transport = find_transport(endpoint, path);
-	if (transport) {
-		clear_configuration(endpoint, transport);
-		bt_bap_stream_set_user_data(stream, NULL);
+		if (media_transport_get_stream(transport) == stream) {
+			clear_configuration(endpoint, transport);
+			item = endpoint->transports;
+		} else {
+			item = item->next;
+		}
 	}
 }