Incomplete A2DP endpoint capabilities cached due to incorrect session version #13
Comments
|
Merged. |
BluezTestBot
pushed a commit
that referenced
this issue
Mar 29, 2022
This fixes the following error for invalid read access when registering
filter for incoming messages:
140632==ERROR: AddressSanitizer: stack-buffer-overflow on address...
#0 0x7f60c185741d in MemcmpInterceptorCommon(...
#1 0x7f60c1857af8 in __interceptor_memcmp (/lib64/libasan.so...
#2 0x55a10101536e in find_by_filter mesh/mesh-io-unit.c:494
#3 0x55a1010d8c46 in l_queue_remove_if ell/queue.c:517
#4 0x55a101014ebd in recv_register mesh/mesh-io-unit.c:506
#5 0x55a10102946f in mesh_net_attach mesh/net.c:2885
#6 0x55a101086f64 in send_reply mesh/dbus.c:153
#7 0x55a101124c3d in handle_method_return ell/dbus.c:216
#8 0x55a10112c8ef in message_read_handler ell/dbus.c:276
#9 0x55a1010dae20 in io_callback ell/io.c:120
#10 0x55a1010dff7e in l_main_iterate ell/main.c:478
#11 0x55a1010e06e3 in l_main_run ell/main.c:525
#12 0x55a1010e06e3 in l_main_run ell/main.c:507
#13 0x55a1010e0bfc in l_main_run_with_signal ell/main.c:647
#14 0x55a10100316e in main mesh/main.c:292
#15 0x7f60c0c6855f in __libc_start_call_main (/lib64/libc.so.6+...
#16 0x7f60c0c6860b in __libc_start_main_alias_1 (/lib64/libc.so.6+...
#17 0x55a101003ce4 in _start (/home/istotlan/bluez/mesh/bluetooth-m...
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 14, 2023
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")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 14, 2023
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")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 14, 2023
Each BAP media transport is associated with a BAP stream. Change their
lookup to use the stream pointer, not path strings stored in BAP stream
user data.
This also fixes use-after-free crashes in pac_clear. They occur because
the lifetime of the path string is either that of media transport or
media endpoint, which may be shorter than the BAP stream. In this case,
pac_clear is entered with invalid pointer in stream user data, which
crashes.
There are a few code paths for this:
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
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
...
Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 14, 2023
Each BAP media transport is associated with a BAP stream. Change their
lookup to use the stream pointer, not path strings stored in BAP stream
user data.
This also fixes use-after-free crashes in pac_clear. They occur because
the lifetime of the path string is either that of media transport or
media endpoint, which may be shorter than the BAP stream. In this case,
pac_clear is entered with invalid pointer in stream user data, which
crashes.
There are a few code paths for this:
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
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
...
Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 14, 2023
Each BAP media transport is associated with a BAP stream. Change their
lookup to use the stream pointer, not path strings stored in BAP stream
user data.
This also fixes use-after-free crashes in pac_clear. They occur because
the lifetime of the path string is either that of media transport or
media endpoint, which may be shorter than the BAP stream. In this case,
pac_clear is entered with invalid pointer in stream user data, which
crashes.
There are a few code paths for this:
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
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
...
Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 14, 2023
Each BAP media transport is associated with a BAP stream. Change their
lookup to use the stream pointer, not path strings stored in BAP stream
user data.
This also fixes use-after-free crashes in pac_clear. They occur because
the lifetime of the path string is either that of media transport or
media endpoint, which may be shorter than the BAP stream. In this case,
pac_clear is entered with invalid pointer in stream user data, which
crashes.
There are a few code paths for this, which can be reproduced by making
sound server delay its SetConfiguration response (e.g. gdb breakpoint),
and disconnecting before it replies:
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
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
...
Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 14, 2023
Each BAP media transport is associated with a BAP stream. Change their
lookup to use the stream pointer, not path strings stored in BAP stream
user data.
This also fixes use-after-free crashes in pac_clear. They occur because
the lifetime of the path string is either that of media transport or
media endpoint, which may be shorter than the BAP stream. In this case,
pac_clear is entered with invalid pointer in stream user data, which
crashes.
There are a few code paths for this. One can be reproduced by making
sound server delay its SetConfiguration response (e.g. gdb breakpoint)
to get dbus timeout, then disconnecting:
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
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
...
Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 15, 2023
Each BAP media transport is associated with a BAP stream. Change their
lookup to use the stream pointer, not path strings stored in BAP stream
user data.
This also fixes use-after-free crashes in pac_clear. They occur because
the lifetime of the path string is either that of media transport or
media endpoint, which may be shorter than the BAP stream. In this case,
pac_clear is entered with invalid pointer in stream user data, which
crashes.
There are a few code paths for this. One can be reproduced by making
sound server delay its SetConfiguration response (e.g. gdb breakpoint)
to get dbus timeout, then disconnecting:
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
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
...
Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 15, 2023
To look up transports, use BAP stream pointers associated with them, not
the path strings stored in the stream user data. This makes it clearer
that transports presented to the sound server correspond to the actual
streams.
This fixes use-after-free crashes in pac_clear. They occur because the
lifetime of the path string is either that of media transport or media
endpoint, which may be shorter than that of the BAP stream. In such
case, pac_clear is entered with invalid pointer in stream user data,
which crashes. There are a few code paths for this. One is making sound
server delay its SetConfiguration response (e.g. gdb breakpoint) to get
dbus timeout, then disconnecting:
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
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
...
Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 15, 2023
To look up transports, use BAP stream pointers associated with them, not
the path strings stored in the stream user data. This makes it clearer
that transports presented to the sound server correspond to the actual
streams.
This fixes use-after-free crashes in pac_clear. They occur because the
lifetime of the path string is either that of media transport or media
endpoint, which may be shorter than that of the BAP stream. In such
case, pac_clear is entered with invalid pointer in stream user data,
which crashes. There are a few code paths for this. One is making sound
server delay its SetConfiguration response (e.g. gdb breakpoint) to get
dbus timeout, then disconnecting:
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
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
...
Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")
pv
added a commit
to pv/bluez
that referenced
this issue
Feb 19, 2023
To look up transports, use BAP stream pointers associated with them, not
the path strings stored in the stream user data. This makes it clearer
that transports presented to the sound server correspond to the actual
streams. The Acquire/etc. of BAP transports are already tied to the
associated stream.
This fixes use-after-free crashes in pac_clear. They occur because the
lifetime of the path string was either that of media transport or media
endpoint, which may be shorter than that of the BAP stream. In such
case, pac_clear is entered with invalid pointer in stream user data,
leading to crash. There are a few code paths for this, e.g. making
sound server delay its SetConfiguration response (e.g. gdb breakpoint)
to get dbus timeout, then disconnecting:
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
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
...
Fixes: 7b1b1a4 ("media: clear the right transport when clearing BAP endpoint")
BluezTestBot
pushed a commit
that referenced
this issue
Sep 20, 2023
Primary/Secundary Counters are supposed to be 16 bytes values, if the
server has implemented them incorrectly it may lead to the following
crash:
=================================================================
==31860==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x607000001878 at pc 0x7f95a1575638 bp 0x7fff58c6bb80 sp 0x7fff58c6b328
READ of size 48 at 0x607000001878 thread T0
#0 0x7f95a1575637 in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:860
#1 0x7f95a1575ba6 in __interceptor_memcmp ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:892
#2 0x7f95a1575ba6 in __interceptor_memcmp ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:887
#3 0x564df69c77a0 in read_version obexd/client/pbap.c:288
#4 0x564df69c77a0 in read_return_apparam obexd/client/pbap.c:352
#5 0x564df69c77a0 in phonebook_size_callback obexd/client/pbap.c:374
#6 0x564df69bea3c in session_terminate_transfer obexd/client/session.c:921
#7 0x564df69d56b0 in get_xfer_progress_first obexd/client/transfer.c:729
#8 0x564df698b9ee in handle_response gobex/gobex.c:1140
#9 0x564df698cdea in incoming_data gobex/gobex.c:1385
#10 0x7f95a12fdc43 in g_main_context_dispatch (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x55c43)
#11 0x7f95a13526c7 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0xaa6c7)
#12 0x7f95a12fd2b2 in g_main_loop_run (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x552b2)
#13 0x564df6977d41 in main obexd/src/main.c:307
#14 0x7f95a10a7d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#15 0x7f95a10a7e3f in __libc_start_main_impl ../csu/libc-start.c:392
#16 0x564df6978704 in _start (/usr/local/libexec/bluetooth/obexd+0x8b704)
0x607000001878 is located 0 bytes to the right of 72-byte region [0x607000001830,0x607000001878)
allocated by thread T0 here:
#0 0x7f95a1595a37 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x564df69c8b6a in pbap_probe obexd/client/pbap.c:1259
This was referenced Nov 22, 2023
BluezTestBot
pushed a commit
that referenced
this issue
Feb 2, 2024
This fixes the following crash when a broadcast stream setup is pending and the device is remove: bluetoothd[37]: src/device.c:device_free() 0x89a500 bluetoothd[37]: GLib: Invalid file descriptor. bluetoothd[37]: ++++++++ backtrace ++++++++ bluetoothd[37]: #1 g_logv+0x270 (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb557e3120] bluetoothd[37]: #2 g_log+0x93 (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb557e3403] bluetoothd[37]: #3 g_io_channel_error_from_errno+0x4a (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb557cd9da] bluetoothd[37]: #4 g_io_unix_close+0x53 (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb55839d53] bluetoothd[37]: #5 g_io_channel_shutdown+0x10f (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb557cdf7f] bluetoothd[37]: #6 g_io_channel_unref+0x39 (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb557ce1e9] bluetoothd[37]: #7 g_source_unref_internal+0x24f (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb557db79f] bluetoothd[37]: #8 g_main_context_dispatch+0x288 (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb557dd638] bluetoothd[37]: #9 g_main_context_iterate.isra.0+0x318 (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb5583b6b8] bluetoothd[37]: #10 g_main_loop_run+0x7f (/usr/lib64/libglib-2.0.so.0.7600.6) [0x7feb557dcaff] bluetoothd[37]: #11 mainloop_run+0x15 (src/shared/mainloop-glib.c:68) [0x662e65] bluetoothd[37]: #12 mainloop_run_with_signal+0x128 (src/shared/mainloop-notify.c:190) [0x663368] bluetoothd[37]: #13 main+0x154b (src/main.c:1454) [0x41521b] bluetoothd[37]: #14 __libc_start_call_main+0x7a (/usr/lib64/libc.so.6) [0x7feb54e1fb8a] bluetoothd[37]: #15 __libc_start_main@@GLIBC_2.34+0x8b (/usr/lib64/libc.so.6) [0x7feb54e1fc4b] bluetoothd[37]: #16 _start+0x25 (src/main.c:1197) [0x416305] bluetoothd[37]: +++++++++++++++++++++++++++
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When first connecting a device, the A2DP session version with be 0x0100 (because the SDP aren't available yet IIUC).
This means that during the discover phase all the end points are going to be checked with GetCapabilities instead of GetAllCapabilities (if the device is AVDTP 1.3 compliant) and so some capabilities will be missing (like Delay reporting). And those incomplete caps will be cached and thus the device will not be queried again.
On subsequent connections the session->version will be 0x0103 but then it's too late, the endpoint capabilities will be taken from the cache and not re-queried with GetAllCapabilities.
The text was updated successfully, but these errors were encountered: