CVE-2023-1902: HCI Connection Creation Dangling State Reference Re-use

Summary

The bluetooth HCI host layer logic not clearing a global reference to a state pointer after handling connection events 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 handle connection state, the HCI stack involves different functions:

1. bt_le_create_conn_ext / bt_le_create_conn_legacy: these functions create a local struct bt_hci_cmd_state_set state variable. They call bt_hci_cmd_state_set_init to store a reference to this local state variable in the global cmd_data array via cmd(buf)->state = state;: https://github.com/zephyrproject-rtos/zephyr/blob/9a75902/subsys/bluetooth/host/hci_core.c#L685 / https://github.com/zephyrproject-rtos/zephyr/blob/9a75902/subsys/bluetooth/host/hci_core.c#L123
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 the state is set, and optionally updating the state accordingly: https://github.com/zephyrproject-rtos/zephyr/blob/9a75902/subsys/bluetooth/host/hci_core.c#L2095
3. To support non-connection related sending, bt_hci_cmd_create initializes cmd(buf)->state to NULL while a command buffer is initially created.

The issue of this way of handling connection state within HCI commands lies in the fact that while handling the completion, the reference to the state structure is not cleared (hci_cmd_done uses cmd(buf)->state, 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 connection-related command, or delays sending it enough such that the corresponding command buffer is correctly re-initialized and the state struct reference is valid again.

The implementation causes a stale reference to the application stack memory to be used as a struct bt_hci_cmd_state_set, 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)->state has first been used as expected, and indicated to bt_le_create_conn_ext / bt_le_create_conn_legacy calling bt_hci_cmd_send_sync that the transmission is completed. As a result, bt_le_create_conn_ext / bt_le_create_conn_legacy return and release their local variables in the process. As other functions get called, they re-claim the stack space for their own local variables, and overwrite the contents in the location which cmd(buf)->state still references. When the second completion event is sent by the malicious/malfunctioning Controller layer, the reference stored in cmd(buf)->state still references the invalidated stack memory, such that this reference is involved in a write operation via atomic_set_bit_to(state->target, state->bit, state->val); (https://github.com/zephyrproject-rtos/zephyr/blob/9a75902/subsys/bluetooth/host/hci_core.c#L2098). In this situation, arbitrary data may reside in the affected memory location (which may or may not be attacker-controllable). As a result, a now corrupted (and potentially attacker-controlled) pointer state->target is used in a write operation.

Impact

A malicious / malfunctioning HCI Controller may cause a dangling reference to be used as a pointer in a write operation in the host layer, resulting in a crash (DoS) or 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)->state is not NULL), the HCI logic should ensure that the state structure reference in cmd(buf)->state is (atomically) cleared and will not be re-used while handling another HCI response.

For example, hci_cmd_done could (atomically) read cmd(buf)->state 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