This stops calling hci_devba everytime the GATT db needs to be loaded
since that causes a raw socket to be open to read back the address
pointed by the index, instead this is done only once at assign_handle
and store in packet_conn_data.
This fixes the following build error:
CC tools/mgmt-tester.o
tools/mgmt-tester.c: In function ‘setup_command_generic’:
tools/mgmt-tester.c:7503:16: error: the comparison will always evaluate
as ‘true’ for the pointer operand in
‘(const struct setup_mgmt_cmd *)test->setup_mgmt_cmd_arr +
(sizetype)(i * 24)’ must not be NULL [-Werror=address]
7503 | for (; test->setup_mgmt_cmd_arr + i; ++i) {
| ^~~~
Following scenario happens when prov is false and we have double free as
mentioned in the below
bluez-5.64/tools/mesh-gatt/prov-db.c:847: freed_arg: "g_free" frees
"in_str".
bluez-5.64/tools/mesh-gatt/prov-db.c:867: double_free: Calling "g_free"
frees pointer "in_str" which has already been freed.
Reported by coverity tool as follows :
bluez-5.64/tools/meshctl.c:1968: freed_arg: "g_free" frees "mesh_dir".
bluez-5.64/tools/meshctl.c:2018: double_free: Calling "g_free" frees
pointer "mesh_dir" which has already been freed.
Reported by coverity tool as follows:
bluez-5.64/obexd/client/pbap.c:929: leaked_storage: Variable "apparam"
going out of scope leaks the storage it points to.
While performing static tool analysis using coverity found following
reports for resouse leak
bluez-5.64/tools/obex-client-tool.c:315: leaked_handle: Handle variable
"sk" going out of scope leaks the handle.
While performing static tool analysis using coverity found following
reports for resouse leak
bluez-5.64/tools/mesh/mesh-db.c:2388: leaked_handle: Handle variable
"fd" going out of scope leaks the handle.
bluez-5.64/tools/mesh/mesh-db.c:2388: leaked_storage: Variable "str"
going out of scope leaks the storage it points to.
While performing static tool analysis using coverity found following
reports for resouse leak
bluez-5.64/tools/l2cap-tester.c:1712: leaked_handle: Handle variable
"new_sk" going out of scope leaks the handle.
While performing static tool analysis using coverity found following
reports for resouse leak
bluez-5.64/tools/create-image.c:124: leaked_storage: Variable "map"
going out of scope leaks the storage it points to.
While performing static tool analysis using coverity found
following reports for resouse leak
bluez-5.64/tools/cltest.c:75: leaked_handle: Handle variable "fd"
going out of scope leaks the handle.
While performing static tool analysis using coverity
found following reports for resouse leak
bluez-5.64/plugins/sixaxis.c:425: alloc_arg:
"get_pairing_type_for_device" allocates memory that is
stored into "sysfs_path".
bluez-5.64/plugins/sixaxis.c:428: leaked_storage: Variable "sysfs_path"
going out of scope leaks the storage it points to.
While performing static tool analysis using coverity
found following reports for resouse leak
bluez-5.64/monitor/jlink.c:111: leaked_storage: Variable "so"
going out of scope leaks the storage it points to.
bluez-5.64/monitor/jlink.c:113: leaked_storage: Variable "so"
going out of scope leaks the storage it points to.
While performing the static analysis using the coverity tool found
following memory leak reports
bluez-5.64/mesh/appkey.c:143: leaked_storage: Variable "key" going
out of scope leaks the storage it points to.
Error: RESOURCE_LEAK (CWE-772):
bluez-5.64/mesh/appkey.c:146: leaked_storage: Variable "key" going
out of scope leaks the storage it points to.
While performing the static tool analysis using coverity tool
found following reports
Error: RESOURCE_LEAK (CWE-772):
bluez-5.64/client/gatt.c:1531: leaked_storage: Variable "service"
going out of scope leaks the storage it points to.
Error: RESOURCE_LEAK (CWE-772):
bluez-5.64/client/gatt.c:2626: leaked_storage: Variable "chrc"
going out of scope leaks the storage it points to.
Error: RESOURCE_LEAK (CWE-772):
bluez-5.64/client/gatt.c:2906: leaked_storage: Variable "desc"
going out of scope leaks the storage it points to.
This adds decoding support for PAC Sink/Source attributes:
< ACL Data TX: Handle 42 flags 0x00 dlen 9
Channel: 64 len 5 sdu 3 [PSM 39 mode Enhanced Credit (0x81)]
{chan 0}
ATT: Read Request (0x0a) len 2
Handle: 0x0017 Type: Sink PAC (0x2bc9)
> ACL Data RX: Handle 42 flags 0x02 dlen 31
Channel: 65 len 27 sdu 25 [PSM 39 mode Enhanced Credit (0x81)]
{chan 0}
Value: 010600000000100301ff0002020302030305041e00f00000
Number of PAC(s): 1
PAC #0:
Codec: LC3 (0x06)
Codec Specific Configuration #0: len 0x03 type 0x01
Codec Specific Configuration: ff00
Codec Specific Configuration #1: len 0x02 type 0x02
Codec Specific Configuration: 03
Codec Specific Configuration #2: len 0x02 type 0x03
Codec Specific Configuration: 03
Codec Specific Configuration #3: len 0x05 type 0x04
Codec Specific Configuration: 1e00f000
If there are multiple notifications in the same frame the callback may
alter it when using l2cap_frame_pull helpers, so instead this passes a
cloned frame with just the expected length so callbacks cannot alter
original frame.
If there is a pending notify multiple the code was not removing before
freeing the object causing the following crash:
Invalid read of size 8
at 0x4A3D10: notify_multiple (gatt-server.c:1703)
by 0x4D05F0: timeout_callback (timeout-glib.c:25)
by 0x4956900: ??? (in /usr/lib64/libglib-2.0.so.0.7000.5)
by 0x49560AE: g_main_context_dispatch
(in /usr/lib64/libglib-2.0.so.0.7000.5)
by 0x49AB307: ??? (in /usr/lib64/libglib-2.0.so.0.7000.5)
by 0x49557C2: g_main_loop_run
(in /usr/lib64/libglib-2.0.so.0.7000.5)
by 0x4D0A34: mainloop_run (mainloop-glib.c:66)
by 0x4D0F2B: mainloop_run_with_signal (mainloop-notify.c:188)
by 0x2B0CD1: main (main.c:1276)
Address 0x6ca35c8 is 136 bytes inside a block of size 144 free'd
at 0x48470E4: free (vg_replace_malloc.c:872)
by 0x415E73: gatt_server_cleanup (device.c:698)
by 0x415E73: attio_cleanup (device.c:715)
by 0x47745B: queue_foreach (queue.c:207)
by 0x490C54: disconnect_cb (att.c:701)
by 0x4CF4AF: watch_callback (io-glib.c:157)
by 0x49560AE: g_main_context_dispatch
(in /usr/lib64/libglib-2.0.so.0.7000.5)
by 0x49AB307: ??? (in /usr/lib64/libglib-2.0.so.0.7000.5)
by 0x49557C2: g_main_loop_run
(in /usr/lib64/libglib-2.0.so.0.7000.5)
by 0x4D0A34: mainloop_run (mainloop-glib.c:66)
by 0x4D0F2B: mainloop_run_with_signal (mainloop-notify.c:188)
by 0x2B0CD1: main (main.c:1276)
This attempt to decode the attribute type if its gatt_db can be loaded:
< ACL Data TX: Handle 3585 flags 0x00 dlen 9
ATT: Write Request (0x12) len 4
Handle: 0x000b Type: Client Characteristic Configuration (0x2902)
Data: 0200
This caches connection information including the device addres so it can
be printed alongside the handle:
> HCI Event: Disconnect Complete (0x05) plen 4
Status: Success (0x00)
Handle: 3585 Address: 68:79:12:XX:XX:XX (OUI 68-79-12)
Reason: Connection Terminated By Local Host (0x16)
On some rare occasions, the peer HID device might disconnect the ctrl
channel when we are trying to connect the intr channel. If this
happens, interrupt_connect_cb() will not be called by btio, and we
will be stuck in "connecting" state. Any future connection attempt to
the peer device will fail because of "busy".
This patch prevents that by checking if we need to report connection
failure when the ctrl channel is disconnected.
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
If there is multiple instances the gatt_db of the instances was not
initialized causing the report_map_attr to be NULL which prevents the
report_map to be read and uhid device to be created.
Fixes: https://github.com/bluez/bluez/issues/298
If device uses RPA it shall only enable wakeup if RPA Resolution has
been enabled otherwise it cannot be programmed in the acceptlist which
can cause suspend to fail.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215768
This adds initiator argument to service_accept so profiles accepting
the connection can use btd_service_is_initiator to determine if the
connection was initiated locally (central) or remotely (peripheral).
After connect the Bluetooth mouse, open two Bluetoothctl at the same time,
when remove the mouse, quickly go to power off,
try to paired the mouse again when I was power on,
found that the error 0x13 was always reported.
try to connect directly,can connect successfully.
but use the info command to query the information of the mouse
and find that the pairing status of the mouse is No.
so I try to delete the paired information in the kernel
through the "* cancel_pairing()" interface.
Definitely `dbus_bool_t b;` must be initialized before comparing it
with current value.
Found by Linux Verification Center (linuxtesting.org) with the SVACE
static analysis tool.
Some branches of execution can make handle (socket) leakage.
Found by Linux Verification Center (linuxtesting.org) with the SVACE
static analysis tool.
According to man buffer allocated by getline() should be freed by
the user program even if getline() failed.
Found by Linux Verification Center (linuxtesting.org) with the SVACE
static analysis tool.
printf() was using function that return dynamic allocated memory as
a parameter.
Found by Linux Verification Center (linuxtesting.org) with the SVACE
static analysis tool.
This treats empty LocalName ("") the same as omitting it so not name is
set in the advertising data since some D-Bus binding seems to have
problems to omit properties at runtime.
Fixes: https://github.com/bluez/bluez/issues/337
