The adapter->discovery_list can function equally well as an indicator of
whether normal discovery or passive scanning is in progress. Normal
discovery always overrides passive scanning so if there's one or more
entries in discovery_list we must be performing normal discovery and not
passive scanning.
store_device_info_cb() is also used as callback for g_idle_add() and
therefore sets device->store_id to zero. During device removal it may be
called manually, which must be done only after the existing
device->store_id is removed from mainloop.
Fix this GLib error (and a bunch of invalid read/writes when
store_device_info_cb() was called after device removal due to this bug):
bluetoothd[1192]: src/device.c:device_remove() Removing device
/org/bluez/hci0/dev_12_34_12_34_12_34
(bluetoothd:1192): GLib-CRITICAL **: g_source_remove: assertion `tag >
0' failed
bluetoothd[1192]: src/device.c:btd_device_unref() Freeing device
/org/bluez/hci0/dev_12_34_12_34_12_34
bluetoothd[1192]: src/device.c:device_free() 0x463a2a0
When doing the Find Included Services GATT procedure, the status of the ATT
procedure was being ignored, and in the case of a timeout it is possible to
crash bluetooth with an invalid memory access.
Valgrind log:
==1755== Invalid read of size 8
==1755== at 0x46971A: find_included_cb (device.c:2964)
==1755== by 0x4465AE: isd_unref (gatt.c:92)
==1755== by 0x446885: find_included_cb (gatt.c:425)
==1755== by 0x448266: disconnect_timeout (gattrib.c:269)
==1755== by 0x4E76BCA: g_timeout_dispatch (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76044: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76377: g_main_context_iterate.isra.24 (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76771: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x40A2EE: main (main.c:583)
==1755== Address 0x69530a8 is 8 bytes inside a block of size 64 free'd
==1755== at 0x4C2874F: free (vg_replace_malloc.c:446)
==1755== by 0x40BFA6: service_filter (watch.c:486)
==1755== by 0x40BC6A: message_filter (watch.c:554)
==1755== by 0x5160A1D: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.2)
==1755== by 0x40AAB7: message_dispatch (mainloop.c:76)
==1755== by 0x4E76BCA: g_timeout_dispatch (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76044: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76377: g_main_context_iterate.isra.24 (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76771: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x40A2EE: main (main.c:583)
==1755==
==1755== Invalid read of size 8
==1755== at 0x4486D5: g_attrib_get_buffer (gattrib.c:657)
==1755== by 0x4467C5: find_included (gatt.c:363)
==1755== by 0x4465AE: isd_unref (gatt.c:92)
==1755== by 0x446885: find_included_cb (gatt.c:425)
==1755== by 0x448266: disconnect_timeout (gattrib.c:269)
==1755== by 0x4E76BCA: g_timeout_dispatch (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76044: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76377: g_main_context_iterate.isra.24 (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76771: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x40A2EE: main (main.c:583)
==1755== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==1755==
==1755==
==1755== Process terminating with default action of signal 11 (SIGSEGV)
==1755== Access not within mapped region at address 0x18
==1755== at 0x4486D5: g_attrib_get_buffer (gattrib.c:657)
==1755== by 0x4467C5: find_included (gatt.c:363)
==1755== by 0x4465AE: isd_unref (gatt.c:92)
==1755== by 0x446885: find_included_cb (gatt.c:425)
==1755== by 0x448266: disconnect_timeout (gattrib.c:269)
==1755== by 0x4E76BCA: g_timeout_dispatch (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76044: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76377: g_main_context_iterate.isra.24 (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x4E76771: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3400.2)
==1755== by 0x40A2EE: main (main.c:583)
Message reference was not dropped in register_agent. This fix following
memory leak reported by valgrind:
454 (184 direct, 270 indirect) bytes in 1 blocks are definitely lost in loss record 207 of 220
at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x513DCF2: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514222E: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5149F46: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514A070: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514AA63: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514B0A5: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5149E0C: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5134D24: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5136088: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5135643: dbus_connection_send_with_reply_and_block (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5130C93: dbus_bus_register (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
102 bytes in 1 blocks are indirectly lost in loss record 154 of 220
at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x514F02F: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514F0DD: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514F239: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514DE0A: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514E3D3: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x513C138: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x513FF4D: dbus_message_iter_append_basic (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5141790: dbus_message_new_error (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5135C70: dbus_connection_dispatch (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x40A747: message_dispatch (mainloop.c:76)
by 0x4E7A91A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3200.3)
168 bytes in 1 blocks are indirectly lost in loss record 185 of 220
at 0x4C2B7B2: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x514F02F: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514F0DD: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514F239: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x513A3B3: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514228F: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5149F46: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514A070: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514AA63: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x514B0A5: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5149E0C: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
by 0x5134D24: ??? (in /lib/x86_64-linux-gnu/libdbus-1.so.3.5.8)
This patch makes it possible to disable the LE auto connections
temporarily through Device1.Disconnect and re-enable them by calling
Device1.Connect().
This patch adds a state variable to track passive scanning and ensures
that LE connections are only created through this discovery procedure
and not the normal (StartDiscovery based) discovery procedure.
Invalid read of size 8
at 0x448200: g_attrib_unregister (gattrib.c:722)
by 0x440476: destroy_thermometer (thermometer.c:167)
by 0x40D849: remove_interface (object.c:656)
by 0x40DAA9: g_dbus_unregister_interface (object.c:1413)
by 0x3DF7A63C9C: g_slist_foreach (gslist.c:894)
by 0x469656: device_remove (device.c:2200)
by 0x45CDC1: adapter_remove (adapter.c:3884)
by 0x45F146: index_removed (adapter.c:5442)
by 0x46BC17: received_data (mgmt.c:252)
by 0x3DF7A47A74: g_main_context_dispatch (gmain.c:2715)
by 0x3DF7A47DA7: g_main_context_iterate.isra.24 (gmain.c:3290)
by 0x3DF7A481A1: g_main_loop_run (gmain.c:3484)
Address 0x40 is not stack'd, malloc'd or (recently) free'd
The function btd_profile_add_custom_prop register a custom property for
an UUID which is valid for every adapter so its user_data cannot be tied
to a single adapter.
To fix this now NULL is passed as user_data and the callbacks checks if
the adapter passed has been registered and if there is an endpoint for
the UUID requested.
With introdution of browsing channel the .init callback is called when
browsing channel connection completes, but in the meantime the remote
device can send commands over control channel.
To fix this the init callaback of control and browsing channel are now
separated into .init_control and .init_browsing so the handler can be
register as soon the respective channel connection completes.
Before 1.3 the kernel wouldn't handle 32 and 128 bit UUIDs properly but
from that revision onwards any type of UUID can be safely added and
removed through mgmt.
