Summary
I spotted a buffer overflow vulnerability at the following location in the Zephyr IEEE 802.15.4 driver source code:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/ieee802154/ieee802154_nrf5.c
Details
Buffer overflow in drivers/ieee802154/ieee802154_nrf5.c:
static int nrf5_tx(const struct device *dev,
enum ieee802154_tx_mode mode,
struct net_pkt *pkt,
struct net_buf *frag)
{
struct nrf5_802154_data *nrf5_radio = NRF5_802154_DATA(dev);
uint8_t payload_len = frag->len;
uint8_t *payload = frag->data;
bool ret = true;
LOG_DBG("%p (%u)", payload, payload_len);
nrf5_radio->tx_psdu[0] = payload_len + NRF5_FCS_LENGTH;
memcpy(nrf5_radio->tx_psdu + 1, payload, payload_len); /* VULN: stack-based buffer overflow due to unchecked payload_len */
/* Reset semaphore in case ACK was received after timeout */
k_sem_reset(&nrf5_radio->tx_wait);
...
PoC
I haven't tried to reproduce these potential vulnerabilities against a live install of the Zephyr OS.
Impact
If the unchecked input above is attacker-controlled and cross a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to arbitrary code execution.
Patches
This has been fixed in:
Summary
I spotted a buffer overflow vulnerability at the following location in the Zephyr IEEE 802.15.4 driver source code:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/ieee802154/ieee802154_nrf5.c
Details
Buffer overflow in drivers/ieee802154/ieee802154_nrf5.c:
PoC
I haven't tried to reproduce these potential vulnerabilities against a live install of the Zephyr OS.
Impact
If the unchecked input above is attacker-controlled and cross a security boundary, the impact of the buffer overflow vulnerability could range from denial of service to arbitrary code execution.
Patches
This has been fixed in: