CVE-2022-3806-hci-send_error_double_free.md

Double Free in bt_spi_send in Error case

Summary

Inconsistent handling of error cases in bluetooth hci may lead to a double free condition of a network buffer.

Description

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 https://github.com/zephyrproject-rtos/zephyr/blob/8a262651af83d4a3257a5e0acbe0b3609ca6c861/drivers/bluetooth/hci/h4.c#L489
• Un-referencing the buffer in the processing loop process_tx: https://github.com/zephyrproject-rtos/zephyr/blob/8a262651af83d4a3257a5e0acbe0b3609ca6c861/drivers/bluetooth/hci/h4.c#L442

This is, however, not always adhered to. For example:

1. bt_spi_send netbuf is unreferenced in the error case bt_spi_transceive fails: https://github.com/zephyrproject-rtos/zephyr/blob/8a262651af83d4a3257a5e0acbe0b3609ca6c861/drivers/bluetooth/hci/spi.c#L446 (however, other error cases do not unreference the netbuf. For example, the case of a too long buffer: https://github.com/zephyrproject-rtos/zephyr/blob/8a262651af83d4a3257a5e0acbe0b3609ca6c861/drivers/bluetooth/hci/spi.c#L429)
2. bt_esp32_send unreferences the netbuf in the timeout error case: https://github.com/zephyrproject-rtos/zephyr/blob/8a262651af83d4a3257a5e0acbe0b3609ca6c861/drivers/bluetooth/hci/hci_esp32.c#L269 (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 https://github.com/zephyrproject-rtos/zephyr/blob/8a262651af83d4a3257a5e0acbe0b3609ca6c861/drivers/bluetooth/hci/spi.c#L446
• hci_tx_thread->process_events->send_cmd buffer un-referencing for bt_send error: https://github.com/zephyrproject-rtos/zephyr/blob/8a262651af83d4a3257a5e0acbe0b3609ca6c861/subsys/bluetooth/host/hci_core.c#L2435

For completeness, the different hci implementations should be re-checked for exhibiting this issue depending on error code paths.

Impact

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.

Proposed Fix

To fix this issue, we need to make sure that all driver functions adhere to the previously mentioned convention: In all error cases, low-level bt_hci_driver.send implementations (such as bt_spi_send, bt_esp32_send) are required not to free/unref the passed network buffer.