Issue Description

In hci_cmd_done, the buf argument being passed as null causes
nullpointer dereference.

This is triggered in case of subsys/bluetooth/host/hci_core.c#send_cmd
calling hci_cmd_done with null pointer after error status of bt_send.

static void send_cmd(void)
{
    ...
    err = bt_send(buf);
    if (err) {
        BT_ERR("Unable to send to driver (err %d)", err);
        k_sem_give(&bt_dev.ncmd_sem);
        // Tobias Scharnowski: Calling hci_cmd_done with buf=NULL
        hci_cmd_done(cmd(buf)->opcode, BT_HCI_ERR_UNSPECIFIED,
                 NULL);
    ...
    }
    ...
}
...
static void hci_cmd_done(u16_t opcode, u8_t status, struct net_buf *buf)
{
    BT_DBG("opcode 0x%04x status 0x%02x buf %p", opcode, status, buf);
    // Tobias Scharnowski: Use of buf without check
    if (net_buf_pool_get(buf->pool_id) != &hci_cmd_pool) {
        BT_WARN("opcode 0x%04x pool id %u pool %p != &hci_cmd_pool %p",
            opcode, buf->pool_id, net_buf_pool_get(buf->pool_id),
            &hci_cmd_pool);
        return;
    }
    ...
}

Source Code References

• Calling hci_cmd_done with NULL buf argument: https://github.com/zephyrproject-rtos/zephyr/blob/zephyr-v2.2.0/subsys/bluetooth/host/hci_core.c#L4100
• Accessing buf argument without NULL pointer check:
  https://github.com/zephyrproject-rtos/zephyr/blob/zephyr-v2.2.0/subsys/bluetooth/host/hci_core.c#L3582

Impact

• Based on the ability of an attacker to influence the success of a
  low-level bluetooth send, this can lead to a DoS.
• Ideas for such influence have not been further investigated, but may
  consist of jamming or causing timeouts (possibly by withholding things
  like acknowledgements or the like)

Patches

This has been fixed in:

• v2.3.0: #24902
• v2.2: #24925
• v1.14: #25089

For more information

If you have any questions or comments about this advisory:

• Open an issue in zephyr
• Email us at Zephyr-vulnerabilities

embargo: 2020-06-29
zepsec: ZEPSEC-67
thanks: Stuart Steffen