Error: INTEGER_OVERFLOW (CWE-190): [#def1] [important]
emulator/amp.c:693:2: cast_overflow: Truncation due to cast operation on "(remain_assoc_len > 248) ? 248 : remain_assoc_len" from 32 to 16 bits.
emulator/amp.c:693:2: overflow_assign: "fragment_len" is assigned from "(remain_assoc_len > 248) ? 248 : remain_assoc_len".
emulator/amp.c:698:2: overflow_sink: "fragment_len", which might have overflowed, is passed to "memcpy(rsp.assoc_fragment, amp->local_assoc + len_so_far, fragment_len)". [Note: The source code implementation of the function has been overridden by a builtin model.]
696| rsp.phy_handle = cmd->phy_handle;
697| rsp.remain_assoc_len = cpu_to_le16(remain_assoc_len);
698|-> memcpy(rsp.assoc_fragment, amp->local_assoc + len_so_far,
699| fragment_len);
700|
Error: INTEGER_OVERFLOW (CWE-190): [#def2] [important]
emulator/amp.c:701:2: cast_overflow: Truncation due to cast operation on "4 + fragment_len" from 32 to 8 bits.
emulator/amp.c:701:2: overflow_sink: "4 + fragment_len", which might have overflowed, is passed to "cmd_complete(amp, 5130, &rsp, 4 + fragment_len)".
699| fragment_len);
700|
701|-> cmd_complete(amp, BT_HCI_CMD_READ_LOCAL_AMP_ASSOC,
702| &rsp, 4 + fragment_len);
703| }
Error: INTEGER_OVERFLOW (CWE-190): [#def4] [important]
emulator/bthost.c:3309:3: cast_overflow: Truncation due to cast operation on "len - offset" from 32 to 8 bits.
emulator/bthost.c:3309:3: overflow_assign: "cp->data_len" is assigned from "len - offset".
emulator/bthost.c:3317:2: overflow_sink: "cp->data_len", which might have overflowed, is passed to "memcpy(cp->data, data + offset, cp->data_len)". [Note: The source code implementation of the function has been overridden by a builtin model.]
3315| }
3316|
3317|-> memcpy(cp->data, data + offset, cp->data_len);
3318|
3319| send_command(bthost, BT_HCI_CMD_LE_SET_PA_DATA, buf,
Allow bthost hooks to receive data from L2CAP LE credit based
connections. Handle LE credit header when receiving, and reassemble
received SDU.
Handle L2CAP LE credit header also in bthost_send_cid.
This adds bthost_set_base which takes create of creating the PA data
using bt_ad to add BAA service data and then generating the PA data
which is then passed to bthost_set_pa_data.
This fixes an array overflow that can happen if the user issues the
LE Set Periodic Advertising Data command with data length exceeding
31 bytes.
The PA data set by the user is copied in an array of fixed length
(31 bytes). However, the data length might exceed 31 bytes. This will
cause an array overflow when the PA data is later processed (for
instance, when sending PA reports).
According to specification, the data length provided at LE Set Periodic
Advertising Data command can be maximum 252 bytes. The stored data len
should also be true to the length copied in the array.
Real bluetooth adapters wouldn't send the page timeout immediately
when trying to page a device, instead it would take a few seconds.
Try to behave more realistically in the emulator and send the page
timeout after 5.12 seconds, which is the default page timeout.
When receiving BIG Sync Terminate command the following crash could be
observed:
Invalid read of size 8
at 0x15FC9F: cmd_big_term_sync (btdev.c:6417)
by 0x15D19D: run_cmd (btdev.c:7269)
by 0x16E7DF: process_cmd (btdev.c:7425)
by 0x16E7DF: btdev_receive_h4 (btdev.c:7516)
by 0x143AB9: vhci_read_callback (vhci.c:77)
by 0x185AAE: io_callback (io-mainloop.c:110)
by 0x187158: mainloop_run (mainloop.c:106)
by 0x188357: mainloop_run_with_signal (mainloop-notify.c:188)
by 0x4EA6B89: (below main) (in /usr/lib64/libc.so.6)
Address 0x53cf678 is 8 bytes inside a block of size 16 free'd
at 0x4845B2C: free (vg_replace_malloc.c:985)
by 0x17E0FE: queue_remove (queue.c:256)
by 0x1497F0: conn_remove (btdev.c:537)
by 0x15FC8A: cmd_big_term_sync (btdev.c:6427)
by 0x15D19D: run_cmd (btdev.c:7269)
by 0x16E7DF: process_cmd (btdev.c:7425)
by 0x16E7DF: btdev_receive_h4 (btdev.c:7516)
by 0x143AB9: vhci_read_callback (vhci.c:77)
by 0x185AAE: io_callback (io-mainloop.c:110)
by 0x187158: mainloop_run (mainloop.c:106)
by 0x188357: mainloop_run_with_signal (mainloop-notify.c:188)
by 0x4EA6B89: (below main) (in /usr/lib64/libc.so.6)
Due to race condition in the vhci kernel driver, we might read not a
vendor response packet, but a HCI reset command. This extra check will
ensure that kernel driver behaves correctly. Otherwise, the HCI setup
process will fail, because our controller will not respond to "missing"
HCI reset command. In result the virtual HCI will be DOWN and without
initialized Bluetooth address, e.g:
> hciconfig
hci2: Type: Primary Bus: Virtual
BD Address: 00:AA:01:01:00:02 ACL MTU: 192:1 SCO MTU: 0:0
UP RUNNING
RX bytes:0 acl:0 sco:0 events:66 errors:0
TX bytes:3086 acl:0 sco:0 commands:66 errors:0
hci1: Type: Primary Bus: Virtual
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:8 acl:0 sco:0 commands:1 errors:0
> dmesg
[1754256.640122] Bluetooth: MGMT ver 1.22
[1754263.023806] Bluetooth: MGMT ver 1.22
[1754265.043775] Bluetooth: hci1: Opcode 0x c03 failed: -110
Calling btdev_receive_h4 without prior logic will allow this function
to print some debug logs. E.g.: in case when the received packet type
is not supported.
> Bluetooth emulator ver 5.66
> vhci0: > ff 00 01 00 ....
> vhci0: Unsupported packet 0xff
The debug callback vhci_debug() already prints new line after each debug
string. Explicit new line in the util_debug call causes double new line
in the output.
bthost commands execute with a delay because events may be sitting in
the socketpair queues. This makes it difficult to ensure, when writing
tests, that certain bthost commands have been handled, before any new
events from VHCI are processed.
To make event ordering possible, add a function that flushes client
bthost/btdev socketpair queues, before processing any new VHCI events.
This is done by pausing VHCI input processing until the kernel
socketpair queues are empty.
Create Connection Cancel shall return Command Complete with error status
when there is no Create Connection that can be canceled. In these
cases, we should not send a (spurious) Connection Complete event.
Fix by keeping a list of pending Create Connection commands, and
returning command errors if there is none pending at the moment.
LE CIS Established Event Transport Latency shall follow the formula from
the spec:
BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 6, Part G
page 3050:
Transport_Latency_C_To_P = CIG_Sync_Delay + FT_C_To_P ×
ISO_Interval - SDU_Interval_C_To_P
Transport_Latency_P_To_C = CIG_Sync_Delay + FT_P_To_C ×
ISO_Interval - SDU_Interval_P_To_C
This fixes the following build error:
emulator/btdev.c: In function ‘le_cis_estabilished’:
emulator/btdev.c:5947:22: error: ‘cis_idx’ may be used
uninitialized [-Werror=maybe-uninitialized]
5947 | int cig_idx, cis_idx;
| ^~~~~~~
Check LE Create CIS input parameter are valid and return correct status
codes (Core v5.3 Vol 4 Part E Sec. 7.8.99).
On current bluetooth-next kernel, this results to
ISO AC 6(i) - Success Failed
ISO AC 7(i) - Success Failed
ISO AC 8(i) - Success Failed
ISO AC 9(i) - Success Failed
ISO AC 11(i) - Success Failed
as in these tests the kernel is sending new Create CIS commands before
it has seen all events from the previous, which is not allowed:
< HCI Command: LE Create Co.. (0x08|0x0064) plen 9 #129 [hci0]
Number of CIS: 2
CIS Handle: 257
ACL Handle: 42
CIS Handle: 258
ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4 #130 [hci0]
LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 29 #131 [hci0]
LE Connected Isochronous Stream Established (0x19)
Status: Success (0x00)
Connection Handle: 257
...
< HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 #132 [hci0]
...
> HCI Event: Command Complete (0x0e) plen 6 #133 [hci0]
LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
...
< HCI Command: LE Create Co.. (0x08|0x0064) plen 5 #134 [hci0]
Number of CIS: 1
CIS Handle: 258
ACL Handle: 42
> HCI Event: Command Status (0x0f) plen 4 #135 [hci0]
LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
Status: ACL Connection Already Exists (0x0b)
> HCI Event: LE Meta Event (0x3e) plen 29 #136 [hci0]
LE Connected Isochronous Stream Established (0x19)
Status: Success (0x00)
Connection Handle: 258
...
The emulator uses Already Exists error code here, not Command
Disallowed, since the Established events are logically generated
immediately after the first status event, even though the kernel hasn't
yet processed them.
CIG shall not be configurable after the first Create CIS until Remove
CIG is issued (Core v5.3 Vol 6 Part B Sec. 4.5.14.3). We currently have
it configurable in the inactive state (Create CIS done and all CIS
closed), which is incorrect.
Track CIG state and allow reconfigure only in nonexistent/configured
state, i.e., when no CIS have been created yet.
Change bthost_send_iso to take packet sequence number and timestamp, and
allow it to send timestamped HCI ISO data packets.
Currently, btdev passes through ISO packets, so this can also be used to
test RX timestamping.
Bluetooth Core specification says the CIG must be in configurable state
in order to accept the SetCIGParameters:
BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 4, Part E page 2553:
'If the Host issues this command when the CIG is not in the
configurable state, the Controller shall return the error
code Command Disallowed (0x0C).'
