CVE-2026-53229
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk37th percentile — higher than 37% of all known CVEs
Summary
In the mlx5e driver for Mellanox network cards, a DMA memory and XDP frame leak was discovered. When sending an XDP_TX packet in XSK mode, if the hardware queue is full, the function does not free the allocated frame or unmap the DMA address, leading to resource leakage.
Risk Assessment
Leakage of DMA memory and XDP frames can exhaust available system resources, potentially causing driver or system crashes. The issue is especially visible during driver unbind, where DMA-API warnings are triggered.
Recommendation
Immediately update the Linux kernel to a version containing the fix (commit that removes the leak). If an update is not possible, consider disabling XDP_TX in XSK mode as a temporary workaround.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries. With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind: DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180 ... DMA-API: Mapped at: debug_dma_map_phys+0x4b/0xd0 dma_map_phys+0xfd/0x2d0 mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core] mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core] mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core] Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.