GHSA-996m-g5pm-w3gv: Permanent loss of transmit capability in the NXP ENET QoS Ethernet driver after an Ethernet link drop

Published Nov 9, 2026
·
Updated

The NXP ENET QoS Ethernet driver in drivers/ethernet/ethnxpenetqos serialises transmission with a binary semaphore, data->tx.txsem, taken in ethnxpenetqostx() and returned only by the transmit-completion interrupt handler txdmadone(). 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 ethnxpenetqosphycb() reacts to carrier loss only by calling netethcarrierset(); 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 ethnxpenetqostx() 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 MACCONFIGURATION. 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 netpkt and the netbuf 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, CONFIGETHNXPENETQOSTXTIMEOUTMS, so that any non-completing DMA — not only a carrier loss — reclaims the transmit slot and the packet.

Affected Software

1 affected component
NXP ENET QoS Ethernet driver

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Enable the transmit watchdog so non-completing DMA reclaims the transmit slot and packet.

    NXP ENET QoS Ethernet driver CONFIG_ETH_NXP_ENET_QOS_TX_TIMEOUT_MS = enabled

Event History

Nov 9, 2026
CVE Published
via OSV·10:04 PM
Data Sourced
via OSV·10:04 PM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Who can realistically trigger this condition?

Anyone able to control the Ethernet link partner or cable can trigger it. Examples given include administratively cycling an attached switch port or restarting auto-negotiation from a peer device; no credentials or user interaction are required.

2

What conditions are required for exploitation?

A link-down/link-up transition must occur while a frame is under transmit DMA. An attacker can make this more reliable by keeping the device transmitting and repeating the link transition.

3

How does the issue affect the device after the link returns?

The transmit-completion interrupt for the outstanding frame does not arrive, leaving the transmit semaphore unavailable. Subsequent transmissions cannot proceed, resulting in a persistent loss of transmit capability.

4

What can reduce exposure if a fix cannot be applied immediately?

Prevent untrusted parties from controlling the physical Ethernet connection or link partner, including switch-port administrative state and peer-driven auto-negotiation. Avoid link transitions while the device is actively transmitting where operationally possible.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203