Skip to main content
← Vulnerabilities

Permanent loss of transmit capability in the NXP ENET QoS Ethernet driver after an Ethernet link drop

6.5MediumCNA
Exploited
No known exploitation
Fix
Fixed in 4.3.2, 4.5.0
Who is exposed
Not reported

Do first: Upgrade to a fixed version: 4.3.2, 4.5.0.

Published
Last modified
7/100 · provisional
None on Exploit-DB, Metasploit or GitHub

Summary

The NXP ENET QoS Ethernet driver can permanently stop transmitting after a momentary Ethernet link drop, so the interface keeps receiving but cannot send anything until the device is reset. An attacker on the adjacent network, without logging in, can trigger this by flapping the link at the right moment, causing a denial of service that lasts beyond the attacker's access to the link.

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

Read the original description

The NXP ENET QoS Ethernet driver in drivers/ethernet/eth_nxp_enet_qos serialises transmission with a binary semaphore, data->tx.tx_sem, taken in eth_nxp_enet_qos_tx() and returned only by the transmit-completion interrupt handler tx_dma_done(). A frame that has been handed to the transmit DMA when the Ethernet link goes down is never written back, so that completion interrupt never arrives. The PHY callback eth_nxp_enet_qos_phy_cb() reacts to carrier loss only by calling net_eth_carrier_set(); it does not stop the DMA, take the descriptors back or release the outstanding frame, and no timeout exists to do so.

The trigger is a link-down/link-up transition that lands while a frame is under the transmit DMA. It can be produced by anyone who controls the link partner or the cable — for example by administratively downing and restoring the attached switch port, or by restarting auto-negotiation from a peer device — and can be made reliable by generating traffic that keeps the device transmitting and repeating the transition. No credentials or user interaction are required, and the trigger is at the link layer rather than over IP.

Because the semaphore is never given back, every subsequent call to eth_nxp_enet_qos_tx() fails with -EBUSY for the remaining life of the boot; restoring the link does not recover the interface, since the link-up path only rewrites MAC_CONFIGURATION. The affected interface continues to receive but can no longer transmit anything — no ARP replies, no TCP acknowledgements, no DHCP renewals — until the device is reset. The net_pkt and the net_buf fragments of the abandoned frame are likewise never unreferenced and never return to their pools. The security-relevant property is persistence: a momentary link flap leaves the interface permanently unable to send, so the denial of service outlasts the attacker's access to the link. There is no confidentiality or integrity impact.

The fix adds a claim/release pair around the outstanding packet so that completion and abandonment are mutually exclusive, aborts an outstanding frame from the PHY callback on carrier loss (stopping the DMA, flushing the MTL transmit queue and reinitialising the descriptor ring), and arms a transmit watchdog, CONFIG_ETH_NXP_ENET_QOS_TX_TIMEOUT_MS, so that any non-completing DMA — not only a carrier loss — reclaims the transmit slot and the packet.

cve.now Index

7Pcve.now Index 7 of 100 · methodology v3 · provisional
  • Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
  • Exposure?/25Unknown. No advisory context yet
  • Reach?/20Unknown. No tracked technology or package matched
  • Severity6.5/10CVSS 6.5
  • No patch0/5No signal

What would change the score

  • Would score about 62 if added to CISA KEV
  • Would score about 57 if CISA's SSVC rates exploitation active
  • Would score about 29 if advisories confirm default setups are exposed

What to do

  • Upgrade to a fixed version: 4.3.2, 4.5.0.

Timeline

  1. CVE published
  2. First seen by cve.now

Affected versions

  • zephyr

    From 3.7.0 · fixed in 4.3.2; From 4.4.0 · fixed in 4.5.0

Evidence 2

  1. Advisory
  2. Patch

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

Questions about CVE-2026-90590

Is CVE-2026-90590 being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

Which versions are affected by CVE-2026-90590?

zephyr: from 3.7.0 before 4.3.2; from 4.4.0 before 4.5.0.Source: cve.now feed data

How do I fix CVE-2026-90590?

Upgrade to a fixed version: 4.3.2, 4.5.0.Source: cve.now feed data