CVE-2026-43371
Received Received - Intake
Memory Leak in Linux Kernel macb Driver

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

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
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's macb network driver. When using an NFS root filesystem on an AMD ZynqMp board, the system may experience a long recovery time after suspend due to how the transmit (tx) ring buffer is handled.

The issue arises because the driver resets the transmit buffer queue pointers (tx_head and tx_tail) to zero without properly handling packets already queued. This causes packets to be silently lost, leading to memory leaks since the associated socket buffers (skbs) are not released.

Additionally, concurrent access to these pointers can cause transmission to get stuck on packets that have been sent but not processed, because the driver incorrectly assumes there are no packets to handle when tx_head equals tx_tail.

The fix involves shuffling the tx ring and skb array so that the first unsent packet is at the start of the tx ring and protecting updates to tx_head and tx_tail with proper locking to avoid concurrency issues.


How can this vulnerability impact me? :

This vulnerability can cause prolonged recovery times after system suspend when using NFS root filesystems on affected hardware, such as the AMD ZynqMp board.

It can lead to memory leaks due to lost packets that are not properly released, potentially degrading system performance or stability over time.

Transmission may become stuck on packets that have already been sent but not processed, causing network communication delays or failures.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is resolved by shuffling 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 the transmit queue pointers (queue->tx_head and queue->tx_tail) are properly protected with the appropriate lock to prevent concurrent write access issues.

Applying the updated Linux kernel version that includes this fix is the recommended immediate mitigation step.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart