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:
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
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
- 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:
embargo: 2023-07-04
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:
bt_le_create_conn_ext
/bt_le_create_conn_legacy
: these functions create a localstruct bt_hci_cmd_state_set
state variable. They callbt_hci_cmd_state_set_init
to store a reference to this local state variable in the globalcmd_data
array viacmd(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#L123hci_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#L2095bt_hci_cmd_create
initializescmd(buf)->state
toNULL
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
usescmd(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 incmd(buf)->state
has first been used as expected, and indicated tobt_le_create_conn_ext
/bt_le_create_conn_legacy
callingbt_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 whichcmd(buf)->state
still references. When the second completion event is sent by the malicious/malfunctioning Controller layer, the reference stored incmd(buf)->state
still references the invalidated stack memory, such that this reference is involved in a write operation viaatomic_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) pointerstate->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 incmd(buf)->state
is (atomically) cleared and will not be re-used while handling another HCI response.For example,
hci_cmd_done
could (atomically) readcmd(buf)->state
and NULL the reference after retrieving it.For more information
If you have any questions or comments about this advisory:
embargo: 2023-07-04