CVE-2026-43371

What it actually does

This is a Linux kernel race/state-management flaw in the Cadence MACB/GEM Ethernet driver. When transmit is disabled and later re-enabled, the hardware transmit buffer queue pointer is reset, but the driver previously only reset software tx_head and tx_tail indexes. Packets already in the transmit ring could be lost without freeing their socket buffers, and concurrent updates from transmit and cleanup paths could leave the driver believing there is no work to process. The practical result is an availability impact: stalled packet transmission, memory leakage, delayed network recovery after suspend/resume, and possible loss of network connectivity on systems using the affected driver. The vulnerability does not indicate confidentiality loss, data tampering, or code execution.

Why it matters to the business

Affected Linux systems that rely on the MACB/GEM Ethernet driver, especially embedded platforms and devices using network-backed filesystems or network-dependent services, can experience prolonged network outages or degraded recovery after suspend/resume or interface state changes. For operational technology, appliances, edge devices, or embedded Linux products, this may cause service interruption, failed remote management, delayed boot or recovery, and increased need for manual intervention. The risk is primarily local and availability-focused; EPSS is very low, there is no CISA KEV listing, and no known mature public exploitation is indicated, so remediation should be planned with normal kernel maintenance urgency unless the affected platform is mission-critical or network-rooted.

How an attack unfolds

An attacker would need local access to an affected Linux system and the ability to influence conditions that disable and re-enable transmit on an interface using the MACB/GEM driver, such as triggering suspend/resume, cycling interface state, or otherwise causing driver reinitialization while transmit activity is present. By causing traffic to remain queued during the transition, the attacker can induce a mismatch between the hardware transmit queue pointer and the driver's software ring indexes. The driver may then lose queued packets, leak associated socket buffers, or fail to process completed transmit descriptors because tx_head and tx_tail appear equal. The attack outcome is a denial-of-service condition against network transmission, potentially resulting in delayed recovery, persistent connectivity loss until new traffic, interface reset, or reboot, and operational disruption for services dependent on that network path.

How to fix it

Update to a Linux kernel build that includes the MACB driver fix which shuffles the transmit ring and transmit skb array before enabling transmit and protects tx_head/tx_tail updates with the appropriate lock. Because no exact fixed package versions were provided, use the kernel packages or board-support packages from the relevant Linux distribution, SoC vendor, device vendor, or long-term-stable kernel branch that explicitly include the fix for this issue. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting users who can suspend/resume or administratively cycle network interfaces, disabling unnecessary suspend states on affected embedded devices, avoiding network-root configurations where feasible, and using watchdog or service recovery mechanisms to reset the interface or reboot the device after network transmit stalls.

How to confirm the fix worked

Confirm that the running kernel or vendor kernel source includes the MACB driver changes for transmit-ring shuffling and locked tx_head/tx_tail updates. Validate package status using the distribution or vendor advisory rather than relying only on upstream kernel version strings, because embedded and vendor kernels may backport fixes. On affected hardware, perform controlled suspend/resume or interface down/up testing while generating transmit traffic, then verify that the interface resumes promptly, packet transmission continues, NFS or other network-backed services recover normally, and kernel logs do not show transmit timeouts, stalled queues, or repeated driver resets. Also monitor memory behavior during repeated cycles to confirm socket-buffer leakage is no longer observed.

Typical attack path

1. Identify a Linux system using the affected MACB/GEM Ethernet driver, commonly on embedded or AMD/Xilinx Zynq-class platforms.
2. Obtain local user-level access or another local mechanism capable of triggering suspend/resume, interface cycling, or similar transmit-disable conditions.
3. Generate or time network traffic so packets are queued in the transmit ring during the disable/re-enable window.
4. Trigger the driver state transition, causing the hardware transmit queue pointer and software tx_head/tx_tail state to become inconsistent.
5. Cause packet loss, socket-buffer leakage, or a transmit-ring stall that degrades or interrupts network connectivity.
6. Maintain disruption by repeatedly triggering the condition or waiting for dependent services, such as network filesystems, to time out or recover slowly.

How to detect it

There are no public exploitation-specific indicators for this issue, and exploitation would mostly resemble local triggering of a driver failure rather than a distinct remote attack. To determine whether the condition may already have occurred, review kernel logs, system journals, and device telemetry for MACB/GEM Ethernet errors around suspend/resume events, interface down/up events, link resets, or sudden network service degradation. Useful sources include dmesg, journald, syslog, kernel ring buffers, network manager logs, embedded device health logs, NFS client logs, and uptime/watchdog records. Look for repeated transmit queue timeouts, driver reset messages, prolonged NFS recovery messages, link flapping after resume, unexplained packet transmission stalls, and correlation with local user activity that triggered suspend/resume or administrative interface changes. Treat these artifacts as evidence of possible exposure or triggering, not definitive malicious exploitation, unless they correlate with unauthorized local access or repeated deliberate triggering.

• macb
• Cadence GEM
• NETDEV WATCHDOG
• transmit queue timed out
• tx timeout
• Transmit timeout
• nfs: server
• not responding, still trying
• suspend entry
• PM: suspend entry
• PM: suspend exit
• link is down
• link is up
• interface reset
• resetting controller

What your security team should do

• Prioritize patching for embedded Linux systems, appliances, and Zynq/ZynqMP-class platforms that use the MACB/GEM Ethernet driver and depend on continuous network availability.
• Inventory systems for use of the macb kernel driver, including vendor board-support kernels and downstream embedded images.
• Apply vendor-provided kernel updates or backported fixes; where exact fixed versions are unavailable, require confirmation that the specific MACB transmit-ring fix is included.
• Restrict local access and administrative capabilities that can suspend, resume, or cycle network interfaces until patched.
• Disable suspend or low-power transitions on critical affected devices if they are not operationally required.
• Add monitoring for transmit queue timeouts, MACB driver resets, NFS recovery delays, and unexpected network-interface stalls.
• For critical devices, test the update under realistic suspend/resume and network-load conditions before broad deployment.
• Because this is not KEV-listed, not associated with ransomware use, and has very low EPSS, handle through standard patch management unless the affected system supports critical network-dependent operations.