Description
In the Linux kernel, the following vulnerability has been resolved:

net: macb: Shuffle the tx ring before enabling tx

Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board,
the rootfs may take an extended time to recover after a suspend.
Upon investigation, it was determined that the issue originates from a
problem in the macb driver.

According to the Zynq UltraScale TRM [1], when transmit is disabled,
the transmit buffer queue pointer resets to point to the address
specified by the transmit buffer queue base address register.

In the current implementation, the code merely resets `queue->tx_head`
and `queue->tx_tail` to '0'. This approach presents several issues:

- Packets already queued in the tx ring are silently lost,
leading to memory leaks since the associated skbs cannot be released.

- Concurrent write access to `queue->tx_head` and `queue->tx_tail` may
occur from `macb_tx_poll()` or `macb_start_xmit()` when these values
are reset to '0'.

- The transmission may become stuck on a packet that has already been sent
out, with its 'TX_USED' bit set, but has not yet been processed. However,
due to the manipulation of 'queue->tx_head' and 'queue->tx_tail',
`macb_tx_poll()` incorrectly assumes there are no packets to handle
because `queue->tx_head == queue->tx_tail`. This issue is only resolved
when a new packet is placed at this position. This is the root cause of
the prolonged recovery time observed for the NFS root filesystem.

To resolve this issue, shuffle the tx ring and tx skb array so that
the first unsent packet is positioned at the start of the tx ring.
Additionally, ensure that updates to `queue->tx_head` and
`queue->tx_tail` are properly protected with the appropriate lock.

[1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm
Published: 2026-05-08
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A bug in the Linux macb driver causes the transmit ring to be incorrectly reset to zero when transmit is disabled. This results in packets already queued in the tx ring being silently lost, leading to memory leaks of skb structures, and can cause the transmitter to become stuck on a packet that has already been sent but not yet processed. The improper manipulation of queue pointers also allows concurrent write access to the head and tail indices, creating a race condition that further degrades the reliability of network transmission.

Affected Systems

The vulnerability affects all machines running the Linux kernel with the macb driver enabled, with a pronounced impact on AMD Zynq UltraScale devices that use a Network File System rootfilesystem. Any system that performs suspend/resume operations and relies on the macb Ethernet controller while the kernel version predates the patch will be affected. This includes embedded boards and appliances that implement the ZynqMP SoC and run an unpatched Linux distribution.

Risk and Exploitability

The CVSS score is 5.5, but the EPSS score is < 1%, indicating a very low exploitation probability. The CVE has not been listed in the CISA KEV catalog, implying no known active exploitation at the time of analysis. Reasoning about the attack vector, a local or privileged user could trigger the defect by initiating a suspend/resume cycle or by forcing a transmit disable/reset sequence, potentially leading to a service interruption. Since the flaw is tied to driver internals and requires control over hardware initialization, it is unlikely to be exploitable from unprivileged remote access, but could be leveraged by a disgruntled insider or through firmware updates.

Generated by OpenCVE AI on May 15, 2026 at 16:27 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the macb driver patch that shuffles the tx ring and protects head and tail updates with locks
  • If immediate kernel upgrade is not feasible, avoid triggering suspend operations that reset the transmit ring or manually restart the networking stack after a suspend to clear the stuck transmission state
  • If the macb interface is not required for the deployment, disable the macb network driver in the system configuration to eliminate the vulnerability

Generated by OpenCVE AI on May 15, 2026 at 16:27 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 15 May 2026 15:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-401
Metrics cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}


Tue, 12 May 2026 02:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-401

Tue, 12 May 2026 00:15:00 +0000


Fri, 08 May 2026 18:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-401

Fri, 08 May 2026 14:45:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: net: macb: Shuffle the tx ring before enabling tx Quanyang observed that when using an NFS rootfs on an AMD ZynqMp board, the rootfs may take an extended time to recover after a suspend. Upon investigation, it was determined that the issue originates from a problem in the macb driver. According to the Zynq UltraScale TRM [1], when transmit is disabled, the transmit buffer queue pointer resets to point to the address specified by the transmit buffer queue base address register. In the current implementation, the code merely resets `queue->tx_head` and `queue->tx_tail` to '0'. This approach presents several issues: - Packets already queued in the tx ring are silently lost, leading to memory leaks since the associated skbs cannot be released. - Concurrent write access to `queue->tx_head` and `queue->tx_tail` may occur from `macb_tx_poll()` or `macb_start_xmit()` when these values are reset to '0'. - The transmission may become stuck on a packet that has already been sent out, with its 'TX_USED' bit set, but has not yet been processed. However, due to the manipulation of 'queue->tx_head' and 'queue->tx_tail', `macb_tx_poll()` incorrectly assumes there are no packets to handle because `queue->tx_head == queue->tx_tail`. This issue is only resolved when a new packet is placed at this position. This is the root cause of the prolonged recovery time observed for the NFS root filesystem. To resolve this issue, shuffle the tx ring and tx skb array so that the first unsent packet is positioned at the start of the tx ring. Additionally, ensure that updates to `queue->tx_head` and `queue->tx_tail` are properly protected with the appropriate lock. [1] https://docs.amd.com/v/u/en-US/ug1085-zynq-ultrascale-trm
Title net: macb: Shuffle the tx ring before enabling tx
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-11T22:23:17.582Z

Reserved: 2026-05-01T14:12:56.006Z

Link: CVE-2026-43371

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-05-08T15:16:48.187

Modified: 2026-05-15T15:17:45.180

Link: CVE-2026-43371

cve-icon Redhat

Severity :

Publid Date: 2026-05-08T00:00:00Z

Links: CVE-2026-43371 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-15T16:30:03Z

Weaknesses