Skip to content
Fencer Intel
medium 6.5

CVE-2026-90590 json

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

published 2d ago modified 2d ago also EUVD-2026-120491 , GHSA-996m-g5pm-w3gv

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.5
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 7%
public exploits
0
none known

Summary

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.

Patch / fix

  • zephyrproject zephyr 4.3.2, 4.5.0

Is CVE-2026-90590 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

Exploit prediction

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

CVSS scores

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

Affected products

  • zephyrproject zephyr

Classification

Weakness
  • CWE-772 Missing Release of Resource after Effective Lifetime

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.