CVE-2023-1901: HCI send_sync Dangling Semaphore Reference Re-use

Summary

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.

Description

To send an HCI command synchronously, the HCI stack involves different functions for its synchronization:

1. bt_hci_cmd_send_sync creates a local semaphore variable (which gets allocated on the stack of bt_hci_cmd_send_sync) and stores a reference to this local semaphore variable in the global cmd_data array via cmd(buf)->sync: https://github.com/zephyrproject-rtos/zephyr/blob/9a75902/subsys/bluetooth/host/hci_core.c#L325
2. hci_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
3. To support asynchronous sending, bt_hci_cmd_create initializes cmd(buf)->sync to NULL while 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 is 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.

Impact

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.

Proposed Fix

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.

For more information

If you have any questions or comments about this advisory:

• Open an issue in zephyr
• Email us at Zephyr-vulnerabilities

embargo: 2023-07-04