CVE-2026-53229

What it actually does

This is a resource leak in the Linux kernel Mellanox/NVIDIA mlx5 Ethernet driver XDP/AF_XDP transmit path. When the XSK branch of mlx5e_xmit_xdp_buff() converts a zero-copy buffer to an xdp_frame and attempts XDP_TX, a transmit failure such as a full XDP send queue can cause the function to return without unmapping the DMA address and without returning the allocated xdp_frame. Because the xdpi_fifo entry is only queued on successful transmit, the normal completion path cannot clean up the leaked DMA mapping or frame. Repeated triggering can accumulate unreleased DMA mappings and kernel memory, potentially causing driver instability, degraded network performance, warnings during device unbind, or denial of service on systems using mlx5 hardware with XDP/AF_XDP workloads.

Why it matters to the business

Organizations running Linux systems with mlx5-based high-performance NICs and XDP/AF_XDP packet-processing workloads may experience network instability, degraded throughput, failed driver reloads, or host disruption if the leak is triggered repeatedly. The risk is highest for packet-processing, load-balancing, DDoS-mitigation, observability, trading, telecom, or container networking platforms that rely on AF_XDP zero-copy. EPSS is low and there is no known CISA KEV listing or reported exploit maturity, so broad exploitation is not currently indicated; however, affected systems often sit on critical network paths, making operational impact disproportionate if the bug is reachable.

How an attack unfolds

An attacker needs a path to cause the affected mlx5 XDP/AF_XDP transmit logic to process traffic under conditions where XDP_TX transmission fails, for example because the XDP send queue is full. In a typical practical scenario, the target already runs an XDP/AF_XDP application on an mlx5 interface, or the attacker has local privileges sufficient to configure such a workload. The attacker then drives traffic patterns that cause packets to enter the XSK branch and be converted into xdp_frame objects. By sustaining pressure until xmit_xdp_frame() returns failure, each failed transmit can leave a DMA mapping and xdp_frame unreleased. Repetition gradually consumes DMA-debug-tracked mappings and kernel resources. The visible result may be kernel DMA-API warnings, memory/resource pressure, degraded NIC behavior, or disruption when the driver or device is unbound/reloaded. There are no public indications of weaponized exploitation or named threat actor use in the supplied data.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the mlx5e XSK cleanup fix for failed XDP_TX transmission. If exact fixed versions are not available from the upstream advisory data, use distribution vendor advisories for Red Hat, Ubuntu, Debian, SUSE, Oracle, Amazon Linux, VMware, or appliance vendors that ship customized kernels. Where immediate patching is not possible, reduce exposure by disabling or avoiding AF_XDP zero-copy/XSK workloads on mlx5 interfaces, disabling nonessential XDP programs using XDP_TX, moving critical packet-processing workloads away from affected mlx5 driver versions, and monitoring for DMA-API warnings or mlx5e instability. Systems not using mlx5 hardware or not using XDP/AF_XDP paths are unlikely to be practically exposed to this specific failure mode.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix by checking the installed kernel package changelog/advisory for the mlx5e XSK DMA/xdp_frame leak fix, or by verifying that the relevant source contains cleanup on the xmit_xdp_frame() failure path in mlx5e_xmit_xdp_buff(), including DMA unmap and xdp_return_frame behavior. Inventory exposed systems by checking for mlx5/mlx5e devices and active XDP/AF_XDP usage. On Linux hosts, validate driver presence with commands such as `ethtool -i <iface>`, `lspci | grep -i mellanox`, and `lsmod | grep mlx5`, and validate XDP attachment with `ip -details link show` or `bpftool net`. After patching, run representative XDP/AF_XDP traffic tests and confirm that repeated transmit failure conditions no longer produce DMA-API leak warnings, increasing pending DMA allocation counts, or mlx5e driver instability.

Typical attack path

1. Identify a Linux host using an mlx5/mlx5e network driver with XDP/AF_XDP zero-copy functionality enabled.
2. Ensure or wait for an XDP program/AF_XDP socket path that uses XDP_TX on the mlx5 interface.
3. Generate traffic or local workload pressure that drives packets through the mlx5e XSK transmit path.
4. Cause the XDP send queue to become full or otherwise make sq->xmit_xdp_frame() fail.
5. Repeat the condition so DMA mappings and xdp_frame objects are leaked over time.
6. Leverage accumulated resource leakage to degrade network service, destabilize the driver, or contribute to host-level denial of service.

How to detect it

Look for signs of prior triggering in kernel logs, persistent journals, crash dumps, and monitoring telemetry from Linux systems using mlx5/mlx5e NICs and XDP/AF_XDP workloads. Primary evidence includes DMA-API debug warnings about pending DMA allocations when the mlx5 PCI device is released, stack traces involving mlx5e_xdp_handle(), mlx5e_xsk_skb_from_cqe_mpwrq_linear(), mlx5e_handle_rx_cqe_mpwrq(), dma_map_phys(), and xdp-related paths, as well as mlx5_core driver reset/unbind events following high XDP traffic. Also review service telemetry for AF_XDP/XDP applications showing transmit queue saturation, dropped packets, sudden throughput degradation, or host memory/resource pressure. Absence of CONFIG_DMA_API_DEBUG may mean the exact leak warning is not logged, so correlate mlx5e instability, XDP transmit failures, and packet-processing anomalies. No reliable network-only IOC is derivable because triggering traffic is workload-dependent and may resemble legitimate high-volume packet processing.

• DMA-API: pci
• device driver has pending DMA allocations while released from device
• DMA-API: Mapped at:
• WARNING: kernel/dma/debug.c:881
• dma_debug_device_change
• debug_dma_map_phys
• dma_map_phys
• mlx5e_xdp_handle
• mlx5e_xsk_skb_from_cqe_mpwrq_linear
• mlx5e_handle_rx_cqe_mpwrq
• mlx5_core
• mlx5e_xmit_xdp_buff
• xdp_convert_zc_to_xdp_frame
• xmit_xdp_frame
• xdp_return_frame
• XDP_TX
• XDPSQ is full
• CONFIG_DMA_API_DEBUG

What your security team should do

• Prioritize patching Linux systems with mlx5/mlx5e NICs that run XDP, AF_XDP, DPDK-adjacent packet processing, load balancing, DDoS mitigation, telemetry capture, or other high-throughput network services.
• Inventory mlx5 interfaces and XDP/AF_XDP usage across servers and appliances; systems without mlx5 hardware or XDP/AF_XDP workloads should be lower priority.
• If patching must be delayed, temporarily disable or reduce reliance on XDP_TX/AF_XDP zero-copy workloads on affected mlx5 interfaces where operationally feasible.
• Monitor kernel logs for DMA-API leak warnings, mlx5_core/mlx5e errors, XDP queue saturation, driver reset/unbind events, and network degradation symptoms.
• Coordinate with platform, network, and SRE teams before changing XDP or kernel settings because mitigations can affect packet-processing performance and service availability.
• Track distribution-specific kernel advisories because fixed package versions may differ from upstream kernel commits and may be backported without changing the apparent upstream kernel version.