CVE-2026-43466

What it actually does

This flaw affects the Linux kernel mlx5e network driver used with NVIDIA/Mellanox mlx5 Ethernet devices. During recovery from a transmit error completion queue entry, the driver resets the DMA FIFO consumer counter but leaves the producer counter unchanged. That desynchronizes software bookkeeping for DMA mappings, causing the driver to unmap stale or incorrect DMA addresses after recovery. The likely effects are kernel warnings, IOMMU/DMA mapping errors, network device instability, packet transmission disruption, and potentially a kernel crash or denial of service. The issue is primarily an availability risk, with a limited integrity concern from incorrect DMA bookkeeping; no confidentiality impact is indicated by the available description.

Why it matters to the business

Systems using affected Linux kernels with mlx5/mlx5e network adapters may experience network outages, degraded throughput, kernel warnings, or crashes when transmit error recovery is triggered. This is most consequential for virtualization hosts, storage networks, Kubernetes nodes, high-performance computing clusters, and data-center servers that rely on Mellanox/NVIDIA ConnectX-class networking. Although the EPSS score is low and there is no known CISA KEV listing or ransomware association, the high availability impact and kernel-level failure mode make timely patching important for production hosts using mlx5 hardware.

How an attack unfolds

An attacker would need to cause or coincide with a transmit error condition on an affected mlx5e interface. Once the driver processes a TX error completion queue entry, the recovery path incorrectly resets only part of the DMA FIFO state. Subsequent transmitted packets cause the producer to write DMA entries at the previous producer position while the consumer reads from the beginning of the FIFO. The driver can then attempt to unmap stale DMA addresses, triggering IOMMU warnings and potentially destabilizing the network driver or kernel. Practical exploitation is hardware- and workload-dependent and may be difficult to reproduce reliably, but a remote attacker capable of stressing the affected network interface could attempt to induce conditions that lead to denial of service.

How to fix it

Apply a Linux kernel update that includes the upstream mlx5e fix for DMA FIFO handling during TX error CQE SQ recovery. The corrective change removes the erroneous reset of dma_fifo_cc in mlx5e_reset_txqsq_cc_pc() so DMA FIFO producer and consumer state remains consistent after recovery. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution, vendor advisory, or long-term stable kernel branch once available. Prioritize hosts with NVIDIA/Mellanox mlx5 Ethernet adapters, especially virtualization, storage, and high-throughput networking systems. If immediate patching is not possible, reduce exposure by limiting untrusted traffic to affected interfaces, moving critical workloads away from affected hosts, disabling or avoiding mlx5e-backed interfaces where operationally feasible, and monitoring for driver/IOMMU warnings that indicate the failure path has been reached.

How to confirm the fix worked

Confirm the running kernel has the vendor backport or upstream fix for the mlx5e DMA FIFO recovery issue. Validate by checking distribution security advisories, kernel changelogs, or source/package metadata for the mlx5e change that removes the dma_fifo_cc reset in mlx5e_reset_txqsq_cc_pc(). Inventory affected systems by identifying hosts with loaded mlx5_core/mlx5e modules or Mellanox/NVIDIA mlx5 PCI devices. After patching and rebooting into the fixed kernel, verify the active kernel version, confirm mlx5_core is loaded from the updated kernel tree, and review dmesg/journal logs under network stress for absence of iommu_dma_unmap_page warnings and mlx5e TX recovery errors.

Typical attack path

1. Identify a reachable Linux system using an affected kernel and mlx5/mlx5e network hardware or virtual functions.
2. Generate sustained or malformed network activity that stresses transmit queues on the affected interface.
3. Trigger or wait for a TX error completion queue entry on the mlx5e transmit path.
4. Cause the mlx5e recovery logic to desynchronize DMA FIFO producer and consumer counters.
5. Continue traffic so the driver consumes stale DMA FIFO entries and attempts invalid DMA unmaps.
6. Observe network disruption, driver instability, kernel warnings, or a host crash resulting in denial of service.

How to detect it

Review kernel logs, system journals, crash dumps, and monitoring telemetry for signs that the mlx5e TX error recovery path was reached and followed by DMA/IOMMU unmap warnings or network driver instability. Useful sources include dmesg, journalctl -k, /var/log/kern.log, /var/log/messages, netconsole output, kdump/vmcore analysis, hypervisor host logs, and infrastructure monitoring that records NIC resets, link flaps, kernel warnings, or unexpected reboots. Look for WARNING traces involving iommu_dma_unmap_page, dma_unmap_page_attrs, mlx5e_tx_wi_dma_unmap, mlx5e_poll_tx_cq, mlx5e_napi_poll, and mlx5_core. Also correlate with spikes in network traffic, transmit queue errors, interface resets, NAPI polling warnings, IOMMU faults, host crashes, or degraded application connectivity. There are no known public threat actors, KEV exploitation, or ransomware campaigns associated with this issue in the provided data, so detection should focus on kernel failure artifacts rather than attacker-specific infrastructure.

• WARNING: CPU:
• iommu_dma_unmap_page
• dma_unmap_page_attrs
• mlx5e_tx_wi_dma_unmap
• mlx5e_poll_tx_cq
• mlx5e_napi_poll
• mlx5_core
• mlx5e_reset_txqsq_cc_pc
• dma_fifo_cc
• dma_fifo_pc
• TX error CQE
• error CQE
• net/mlx5e
• Modules linked in: mlx5
• mlx5_vdpa
• mlx5_ib
• mlx5_vfio_pci
• mlx5_fwctl
• RIP: 0010:iommu_dma_unmap_page
• Call Trace:
• __napi_poll
• net_rx_action
• handle_softirqs

What your security team should do

• Inventory Linux systems using mlx5/mlx5e network hardware, including bare-metal servers, hypervisors, Kubernetes nodes, and systems using SR-IOV or VFIO with mlx5 devices.
• Prioritize patching exposed or high-availability systems that rely on mlx5e interfaces for production, storage, cluster, or virtualization traffic.
• Track Linux distribution and hardware vendor advisories for fixed kernel package versions because exact fixed versions were not provided in the input.
• Reboot into the corrected kernel after patching; live patching may not fully replace affected driver state depending on vendor implementation.
• Monitor kernel logs for DMA/IOMMU warnings and mlx5e transmit queue recovery messages until all affected systems are remediated.
• If patching is delayed, reduce untrusted traffic paths to affected interfaces and consider workload migration from vulnerable hosts with critical availability requirements.
• Create SIEM alerts for the specific kernel warning and call-trace indicators associated with this issue.