CVE-2023-4265: Two potential buffer overflow vulnerabilities in Zephyr USB code

Summary

While reading the Zephyr code related to USB, I noticed a couple of potential buffer overflow vulnerabilities in the following locations:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/usb/device/usb_dc_native_posix.c#L359
https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/usb/device/class/netusb/function_rndis.c#L841

Details

The first potential buffer overflow vulnerability is located in the following function:

int usb_dc_ep_write(const uint8_t ep, const uint8_t *const data, const uint32_t data_len, uint32_t * const ret_bytes) { LOG_DBG("ep %x len %u", ep, data_len);

if (!usbip\_ctrl.attached || !usbip\_ep\_is\_valid(ep)) {
    LOG\_ERR("Not attached / Invalid endpoint: EP 0x%x", ep);
    return \-EINVAL;
}

/\* Check if IN ep \*/
if (USB\_EP\_GET\_DIR(ep) != USB\_EP\_DIR\_IN) {
    return \-EINVAL;
}

/\* Check if ep enabled \*/
if (!usbip\_ep\_is\_enabled(ep)) {
    LOG\_WRN("ep %x disabled", ep);
    return \-EINVAL;
}

if (USB\_EP\_GET\_IDX(ep) \== 0) {
    if (!usbip\_send\_common(ep, data\_len)) {
        return \-EIO;
    }

    if (usbip\_send(ep, data, data\_len) != data\_len) {
        return \-EIO;
    }
} else {
    uint8\_t ep\_idx \= USB\_EP\_GET\_IDX(ep);
    struct usb\_ep\_ctrl\_prv \*ctrl \= &usbip\_ctrl.in\_ep\_ctrl\[ep\_idx\];

    memcpy(ctrl\->buf, data, data\_len); /\* VULN \*/
    ctrl\->buf\_len \= data\_len;
}

if (ret\_bytes) {
    \*ret\_bytes \= data\_len;
}

return 0;

}

A check on data_len is missing. If data and data_len are attacker-controlled, the fixed-size buffer buf in the following structure could overflow during memcpy(), thus potentially leading to denial of service or arbitrary code execution:

struct usb_ep_ctrl_prv { u8_t ep_ena; u16_t mps; usb_dc_ep_callback cb; u32_t data_len; u8_t buf[64]; u8_t buf_len; };

The second potential buffer overflow vulnerability is located in the following function:

static int handle_encapsulated_rsp(uint8_t **data, uint32_t *len) { struct net_buf *buf;

LOG\_DBG("");

buf \= net\_buf\_get(&rndis\_tx\_queue, K\_NO\_WAIT);
if (!buf) {
    LOG\_ERR("Error getting response buffer");
    \*len \= 0U;
    return \-ENODATA;
}

if (VERBOSE\_DEBUG) {
    net\_hexdump("RSP <", buf\->data, buf\->len);
}

memcpy(\*data, buf\->data, buf\->len); /\* VULN \*/
\*len \= buf\->len;

net\_buf\_unref(buf);

return 0;

}

A check on buf->len is missing. If buf->data and buf->len are attacker-controlled, the data buffer could overflow due to memcpy(), thus potentially leading to denial of service or arbitrary code execution.

PoC

I haven’t tried to reproduce these potential vulnerabilities against a live install of the Zephyr OS.

Impact

If the vulnerabilities are confirmed, their impact could range from denial of service to arbitrary code execution.