Disclaimer: Our finding of this issue has been reproduced in our fuzzer on a target built from commit e1dddf7befa7309bd2afc567b2e00d2e7362f7c4. The original target was CVE-2021-3329 (which can be built via this script). Based on reviewing the source code, we concluded issue still applies as of the latest commit at time of writing (commit 9a75902).
The bluetooth HCI host layer logic not clearing a global reference to a semaphore after synchronously sending HCI commands may allow a malicious HCI Controller to cause the use of a dangling reference in the host layer, leading to a crash (DoS) or potential RCE on the Host layer.
To send an HCI command synchronously, the HCI stack involves different functions for its synchronization:
bt_hci_cmd_send_synccreates a local semaphore variable (which gets allocated on the stack ofbt_hci_cmd_send_sync) and stores a reference to this local semaphore variable in the globalcmd_dataarray viacmd(buf)->sync: https://github.com/zephyrproject-rtos/zephyr/blob/9a75902/subsys/bluetooth/host/hci_core.c#L325hci_cmd_done, which is called while handling sending completion (via the reception of matching completion or status priority HCI events, or in certain error cases), checks whether the reference to this synchronization semaphore is set, and optionally giving/releasing the semaphore: https://github.com/zephyrproject-rtos/zephyr/blob/9a75902/subsys/bluetooth/host/hci_core.c#L2102- To support asynchronous sending,
bt_hci_cmd_createinitializescmd(buf)->synctoNULLwhile a command buffer is initially created.
The issue of this way of handling synchronous sending of HCI commands lies in the fact that while handling the completion, the reference to the synchronization semaphore is not cleared (hci_cmd_done uses cmd(buf)->sync, but never clears the reference).
This implementation works correctly as long as the HCI Controller layer always sends completion/status priority events only once for each synchronously-sent command, or delays sending it enough such that the corresponding command buffer is correctly re-initialized and the semaphore reference valid again.
The implementation causes a stale reference to the application stack memory to be used as a semaphore, however, if the Controller layer sends a second completion event for the same command before it is re-initialized for sending a new HCI command. In this situation, the pointer stored in cmd(buf)->sync has first been used as expected, and indicated to bt_hci_cmd_send_sync that the transmission is completed. As a result, bt_hci_cmd_send_sync returns and releases its local variables in the process. Another function re-claims the stack space for its own local variables, and overwrites the contents in the location which cmd(buf)->sync still references. When the second completion event is sent by the malicious/malfunctioning Controller layer, the reference stored in cmd(buf)->sync still references the invalidated stack memory, such that this reference is used via k_sem_give(cmd(buf)->sync); (https://github.com/zephyrproject-rtos/zephyr/blob/9a75902/subsys/bluetooth/host/hci_core.c#L2104). In this situation, arbitrary data may reside in the affected memory location (which may or may not be attacker-controllable), and may be wrongly used as a pointer to a k_sem structure in a call to k_sem_give.
A malicious / malfunctioning HCI Controller may cause a dangling reference to be used as a semaphore object in the host layer, resulting in a crash (DoS) or potential Remote Code Execution (RCE) on the Bluetooth host layer.
To avoid this issue, when receiving HCI responses to synchronously sent HCI commands (cmd(buf)->sync is not NULL), the HCI logic should ensure that the semaphore reference in cmd(buf)->sync is (atomically) cleared and will not be re-used while handling another HCI response.
For example, hci_cmd_done could (atomically) read cmd(buf)->sync and NULL the reference after retrieving it.