CVE-2026-90591: zephyrproject zephyr · Memory-safety
Affects zephyrproject zephyrSource CVE Database V5
Not known to be exploited · CVSS 7.5 High : upgrade to 4.5.0 or 4.3.2 soon.
Data as of 9 Nov 2026, 22:18 UTC
Thin evidence
One scorer or none| CNA (zephyr) | CVSS 3.1 | 7.5 |
|---|
- Patch
- Available – fixed in 4.5.0, 4.3.2
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 9 Nov 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 9 Nov 2026.
What to do
Upgrade zephyrproject zephyr to 4.5.0 or 4.3.2.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| zephyrprojectzephyr | Affected
| Fixed in
|
| zephyrprojectzephyr | Affected
| Fixed in
|
GitHubzephyrpkg:github/zephyrOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
The NXP ENET-QOS Ethernet driver's receive work handler eth_nxp_enet_qos_rx() in drivers/ethernet/eth_nxp_enet_qos hands each processed descriptor back to the DMA by writing desc->read.control = rx_desc_refresh_flags, which sets OWN_FLAG and BUF1_ADDR_VALID_FLAG. RDES0 of a receive descriptor is the DMA buffer address in read format, but the hardware write-back aliases that word with the VLAN tag fields (or, for a context descriptor, the timestamp low word), so it is destroyed on every completion. The success path rewrites desc->read.buf1_addr before re-arming; the four drop paths — errored or non-first descriptor, net_pkt_rx_alloc() failure, invalid descriptor length, and net_pkt_get_frag() failure — did not, re-arming the ring slot with the write-back residue as its DMA target address. The drop paths are driven entirely by received traffic and need no privilege or special configuration. With the defaults for this driver (CONFIG_NET_BUF_DATA_SIZE of 128 and 16 receive descriptors) a single full-size frame consumes twelve ring slots and twelve K_NO_WAIT fragment allocations, so a short burst of frames sent to the device exhausts the receive pools and reaches the allocation-failure paths; a frame with a receive error, or any frame whose first descriptor was already dropped, reaches the non-first-descriptor path. Once a slot has been poisoned, the DMA writes the next frame received in that slot to an address derived from the frame's VLAN tag fields rather than to a receive buffer. On the supported MCX SoCs that address falls in flash or reserved space, so the transfer raises a fatal bus error that the driver only logs — there is no reset or recovery path — and reception stops permanently until the device is rebooted; where the write is silently discarded instead, the untouched buffer is later handed to the network stack with a length, delivering stale buffer contents as if they were a received frame. A single triggering event is enough to make the condition persistent, so an attacker able to send traffic to the device can permanently disable its network interface.