Skip to content
Fencer Intel
medium 6.8

CVE-2026-75084 json

Out-of-bounds write in the TI CC1200 IEEE 802.15.4 driver from an unvalidated radio-supplied packet length

published 28d ago modified 7d ago also EUVD-2026-101341 , GHSA-pgg5-wwxw-vmj8

Unreviewed: the maintainers' own advisory

Published by the maintainers on their GitHub repository zephyrproject-rtos/zephyr. GitHub has not reviewed it into the GitHub Advisory Database, so the affected packages and versions are the maintainers' word. Read the full advisory on GitHub.

cvss
6.8
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.3%
EPSS 0.3% chance of exploitation in 30 days, percentile 21%
public exploits
0
none known

Summary

The CC1200 sub-GHz IEEE 802.15.4 driver takes the PHY packet length from the first byte of the radio's RX FIFO in get_packet_length() and validates it in verify_rxfifo_validity() (drivers/ieee802154/ieee802154_cc1200.c). That validation only enforced a lower bound (pkt_len < 3); its second clause rejects a FIFO that holds more bytes than declared and therefore never bounds large values. Because the driver configures the radio for variable packet length with PKT_LEN = 0xFF, the length byte is an over-the-air value of 0-255 that reached net_pkt_rx_alloc_with_buffer() and the subsequent SPI burst read unclamped.

An unauthenticated attacker within radio range can transmit a frame that presents a length byte above the IEEE 802.15.4 maximum of 127 while the chip's 128-byte RX FIFO has not overflowed, so the driver's RX_FIFO_ERROR pre-check does not fire. Reaching this state depends on RF framing and timing, since the RX thread is driven off the PKT_SYNC_RXTX signal and may sample the FIFO before a packet is complete; no pairing, authentication, or user interaction is required.

With the default CONFIG_NET_BUF_FIXED_DATA_SIZE and CONFIG_NET_BUF_DATA_SIZE=128, an allocation larger than one fragment is satisfied by a chain of fragments, but read_rxfifo_content() performs a single SPI burst of pkt_len bytes into the first fragment's buf->data and then calls net_buf_add() with the same length. A length above 128 therefore writes up to 127 bytes past the end of a fragment in the contiguous rx_bufs pool and leaves a net_buf whose len exceeds its capacity. The overflowing bytes are FIFO-underflow output rather than attacker-chosen data, so the practical impact is network-buffer-pool corruption and crashes rather than a controlled write. Only builds that enable CONFIG_IEEE802154_CC1200 with an attached CC1200 radio are affected.

Patch / fix

  • zephyrproject zephyr 4.3.2, 4.5.0

Is CVE-2026-75084 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
26d ago

Exploit prediction

0.29% chance of exploitation in the next 30 days, higher than 21% of all scored CVEs (FIRST EPSS, 2026-11-11).

CVSS scores

assigned by version score vector
CNA 3.1 6.8 CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H

Affected products

  • zephyrproject zephyr

Classification

Weakness

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

The maintainers of zephyrproject-rtos/zephyr published their own advisory on GitHub. Reviewed sources take precedence over it.