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:
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#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_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:
embargo: 2023-07-04
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:
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#L2102bt_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_doneusescmd(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)->synchas first been used as expected, and indicated tobt_hci_cmd_send_syncthat the transmission is completed. As a result,bt_hci_cmd_send_syncreturns 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 whichcmd(buf)->syncstill references. When the second completion event is sent by the malicious/malfunctioning Controller layer, the reference stored incmd(buf)->syncstill references the invalidated stack memory, such that this reference is used viak_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 ak_semstructure in a call tok_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)->syncis not NULL), the HCI logic should ensure that the semaphore reference incmd(buf)->syncis (atomically) cleared and will not be re-used while handling another HCI response.For example,
hci_cmd_donecould (atomically) readcmd(buf)->syncand NULL the reference after retrieving it.For more information
If you have any questions or comments about this advisory:
embargo: 2023-07-04