Skip to main content

Linux kernel macb driver CVE-2026-43371

| EUVDEUVD-2026-28677 MEDIUM
Memory Leak (CWE-401)
2026-05-08 Linux GHSA-53cc-xh3p-4x9v
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
Analysis Generated
May 15, 2026 - 17:32 vuln.today
CVSS changed
May 15, 2026 - 15:22 NVD
5.5 (MEDIUM)
Patch available
May 08, 2026 - 16:18 EUVD
CVE Published
May 08, 2026 - 14:21 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

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

AnalysisAI

Memory leak and denial-of-service in the Linux kernel macb network driver (used in AMD ZynqMP platforms) allows local authenticated users to cause prolonged network disruption and system resource exhaustion. The flaw manifests during suspend/resume cycles when the transmit ring pointer resets incorrectly, silently dropping queued packets without releasing their memory, and causing the driver to become stuck waiting for already-transmitted packets. Real-world impact observed in NFS rootfs recovery delays. EPSS score of 0.02% (7th percentile) indicates low exploitation likelihood. Vendor patches available across multiple stable kernel branches (6.1.167, 6.6.130, 6.12.78, 6.18.20, 6.19.9).

Technical ContextAI

The macb driver implements the Ethernet controller for AMD (formerly Xilinx) Zynq UltraScale+ platforms. According to the Zynq UltraScale TRM, disabling transmit resets the transmit buffer queue pointer to the base address register value. The vulnerable code improperly resets only the software pointers (tx_head and tx_tail) to zero without accounting for the hardware behavior, creating a synchronization mismatch between driver state and hardware state. This triggers CWE-401 (Missing Release of Memory after Effective Lifetime) as skb structures remain allocated but unreachable. The vulnerability affects the driver's suspend/resume path where transmit is disabled and re-enabled. The CPE identifiers indicate broad Linux kernel exposure, though actual impact is limited to systems using the macb hardware (primarily AMD ZynqMP SoCs). The race condition between macb_tx_poll(), macb_start_xmit(), and the reset logic occurs because pointer updates lack proper locking during the critical section.

RemediationAI

Apply vendor-released patches from the Linux stable kernel branches: upgrade to Linux 6.1.167 or later for 6.1.x series, 6.6.130 or later for 6.6.x series, 6.12.78 or later for 6.12.x series, 6.18.20 or later for 6.18.x series, or 6.19.9 or later for 6.19.x series. Upstream fixes are available in commits 0a47c3889fcd (mainline), c6783bfa31a5, 88f974fe118c, 58f5d34f88e8, 403182e0771b, and 881a0263d502 (stable branches) at https://git.kernel.org/stable/. The patches implement proper tx ring shuffling before re-enabling transmission and add locking to protect concurrent access to tx_head and tx_tail pointers. For systems unable to immediately upgrade, compensating controls include: (1) disable system suspend/resume functionality if not operationally required (trade-off: loss of power management benefits), (2) implement monitoring for abnormal memory growth in kernel networking subsystem and automatic system restart when thresholds exceeded (trade-off: service interruption during restart), (3) avoid NFS root filesystems on affected platforms until patched (trade-off: requires local storage or alternative boot mechanisms). Note that disabling the macb driver entirely prevents network connectivity and is not a viable mitigation for most deployments. No configuration-based workaround exists to prevent the driver state corruption during suspend/resume cycles.

More in Amd

View all
CVE-2021-22986 CRITICAL POC
9.8 Mar 31

On BIG-IP versions 16.0.x before 16.0.1.1, 15.1.x before 15.1.2.1, 14.1.x before 14.1.4, 13.1.x before 13.1.3.6, and 12.

CVE-2020-6103 CRITICAL POC
9.9 Jul 20

An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.

CVE-2020-6102 CRITICAL POC
9.9 Jul 20

An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.

CVE-2020-6101 CRITICAL POC
9.9 Jul 20

An exploitable code execution vulnerability exists in the Shader functionality of AMD Radeon DirectX 11 Driver atidxx64.

CVE-2020-6100 CRITICAL POC
9.9 Jul 20

An exploitable memory corruption vulnerability exists in AMD atidxx64.dll 26.20.15019.19000 graphics driver. Rated criti

CVE-2018-6546 CRITICAL POC
9.8 Apr 13

plays_service.exe in the plays.tv service before 1.27.7.0, as distributed in AMD driver-installation packages and Gaming

CVE-2021-3653 HIGH POC
8.8 Sep 29

A flaw was found in the KVM's AMD code for supporting SVM nested virtualization. Rated high severity (CVSS 8.8), this vu

CVE-2020-12138 HIGH POC
8.8 Apr 27

AMD ATI atillk64.sys 5.11.9.0 allows low-privileged users to interact directly with physical memory by calling one of se

CVE-2019-5098 HIGH POC
8.6 Dec 05

An exploitable out-of-bounds read vulnerability exists in AMD ATIDXX64.DLL driver, version 26.20.13001.29010. Rated high

CVE-2015-7724 HIGH POC
7.8 Jun 07

AMD fglrx-driver before 15.9 allows local users to gain privileges via a symlink attack. Rated high severity (CVSS 7.8),

CVE-2015-7723 HIGH POC
7.8 Jun 07

AMD fglrx-driver before 15.7 allows local users to gain privileges via a symlink attack. Rated high severity (CVSS 7.8),

CVE-2023-1048 HIGH POC
7.8 Feb 26

A vulnerability, which was classified as critical, has been found in TechPowerUp Ryzen DRAM Calculator 1.2.0.5.sys. Rate

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

CVE-2026-43371 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy