Impact
Inconsistent handling of error cases in bluetooth hci may lead
to a double free condition of a network buffer.
Details
In a bluetooth driver, when sending a packet via bt_send fails in the
lower driver's send function (such as bt_spi_send), then the
convention is that the ownership remains with the caller of bt_send.
This means that in the error case, the caller of bt_send will clean up
all references to the netbuf it provided to bt_send(net_buf *buf).
This convention is observed by most driver functions. For example:
h4_send handles sending packets by indicating success in all cases
initially, and then cleaning up the reference itself.
- Indicating success in
h4_send
- Un-referencing the buffer in the processing loop
process_tx:
This is, however, not always adhered to. For example:
bt_spi_send netbuf is unreferenced in the error case
bt_spi_transceive fails:
(however, other error cases do not unreference the netbuf. For example,
the case of a too long buffer:
|
} while ((rxmsg[STATUS_HEADER_READY] != READY_NOW || |
)bt_esp32_send unreferences the netbuf in the timeout error case:
(for the other error case "unknown type", however, the function
indicates a zero result, in which case the convention is not broken. So
only the presumably much less frequently observed timeout case breaks
the convention)
Bug trigger source code references:
bt_spi_send unref despite error case
hci_tx_thread->process_events->send_cmd buffer un-referencing for
bt_send error:
For completeness, the different hci implementations should be re-checked
for exhibiting this issue depending on error code paths.
A possible attack scenario here could be an attacker who compromised a
radio chip and then proceeds to attack the bluetooth host stack via the
HCI interface. Such an attacker could also be in a position to induce
SPI errors on the sending side such as spamming traffic or indicating
errors to the sender (e.g., in spi flow control). An attacker which is
able to induce errors in different SPI bluetooth sending functions can
cause a double free scenario on a network buffer. I have not checked the
exploitability of this specific situation, but apart from a simple crash
(DoS), double frees are typically a strong primitive for an attacker to
achieve more with this, such as RCE.
Patches
Credits
Tobias Scharnowski
Simon Woerner
Felix Buchmann
For more information
If you have any questions or comments about this advisory:
embargo: 2023-01-17
Scepticz Analyst
Impact
Inconsistent handling of error cases in bluetooth hci may lead
to a double free condition of a network buffer.
Details
In a bluetooth driver, when sending a packet via
bt_sendfails in thelower driver's send function (such as
bt_spi_send), then theconvention is that the ownership remains with the caller of
bt_send.This means that in the error case, the caller of
bt_sendwill clean upall references to the netbuf it provided to
bt_send(net_buf *buf).This convention is observed by most driver functions. For example:
h4_sendhandles sending packets by indicating success in all casesinitially, and then cleaning up the reference itself.
h4_sendzephyr/drivers/bluetooth/hci/h4.c
Line 489 in 8a26265
process_tx:zephyr/drivers/bluetooth/hci/h4.c
Line 442 in 8a26265
This is, however, not always adhered to. For example:
bt_spi_sendnetbuf is unreferenced in the error casebt_spi_transceivefails:zephyr/drivers/bluetooth/hci/spi.c
Line 446 in 8a26265
(however, other error cases do not unreference the netbuf. For example,
the case of a too long buffer:
zephyr/drivers/bluetooth/hci/spi.c
Line 429 in 8a26265
bt_esp32_sendunreferences the netbuf in the timeout error case:zephyr/drivers/bluetooth/hci/hci_esp32.c
Line 269 in 8a26265
(for the other error case "unknown type", however, the function
indicates a zero result, in which case the convention is not broken. So
only the presumably much less frequently observed timeout case breaks
the convention)
Bug trigger source code references:
bt_spi_sendunref despite error casezephyr/drivers/bluetooth/hci/spi.c
Line 446 in 8a26265
hci_tx_thread->process_events->send_cmdbuffer un-referencing forbt_senderror:zephyr/subsys/bluetooth/host/hci_core.c
Line 2435 in 8a26265
For completeness, the different hci implementations should be re-checked
for exhibiting this issue depending on error code paths.
A possible attack scenario here could be an attacker who compromised a
radio chip and then proceeds to attack the bluetooth host stack via the
HCI interface. Such an attacker could also be in a position to induce
SPI errors on the sending side such as spamming traffic or indicating
errors to the sender (e.g., in spi flow control). An attacker which is
able to induce errors in different SPI bluetooth sending functions can
cause a double free scenario on a network buffer. I have not checked the
exploitability of this specific situation, but apart from a simple crash
(DoS), double frees are typically a strong primitive for an attacker to
achieve more with this, such as RCE.
Patches
Credits
Tobias Scharnowski
Simon Woerner
Felix Buchmann
For more information
If you have any questions or comments about this advisory:
embargo: 2023-01-17