# CVE-2026-75084: Out-of-bounds write in the TI CC1200 IEEE 802.15.4 driver from an unvalidated radio-supplied packet length

> An attacker within radio range can cause a buffer overflow in the TI CC1200 driver, leading to system crashes and denial of service.

- **Severity:** Medium 6.8 (`CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 14 Oct 2026
- **Updated:** 16 Oct 2026
- **Also known as:** GHSA-pgg5-wwxw-vmj8

## What is CVE-2026-75084?

CVE-2026-75084 is a medium-severity memory corruption vulnerability in zephyrproject zephyr, published on 14 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

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.

Weakness: CWE-787 (Out-of-bounds Write)

## Which versions are affected by CVE-2026-75084?


## How do I fix CVE-2026-75084?

No fix has been published for CVE-2026-75084 yet. Limit exposure of the affected software until one is available.

## Is CVE-2026-75084 being exploited?

There is no known exploitation of CVE-2026-75084 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-75084 and fix it if it is affected.

What it is: CVE-2026-75084 is a medium-severity memory corruption vulnerability in zephyrproject zephyr, published on 14 Oct 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2026-75084 in the wild and no public exploit code.

Affected product: zephyrproject zephyr. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-75084/ (Markdown: https://insights.sbomify.com/CVE-2026-75084/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-75084
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-75084
- OSV: https://osv.dev/vulnerability/CVE-2026-75084

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-75084/
Summaries are generated and may contain mistakes; the official description above is the record.