Linux kernel mlx5_ib: dereg of a device-memory MR unmaps an address that was never DMA-mapped

CVSS 5.5CVE-2025-21888Firmware, BMC & network fabriccurated

Impact

Memory regions of type DM (device memory) carry no umem, but __mlx5_ib_dereg_mr() took the umem branch in mlx5_free_priv_descs() and called dma_unmap_single() on an address that was never mapped. The result is an IOMMU WARN splat on every such deregistration and an unmap of a DMA address the driver does not own. On a GPU node this sits in the ConnectX RDMA path that NCCL, GPUDirect and storage clients run over: any local process holding an ib_uverbs handle can trigger it by creating and destroying a DM MR, so the noise and the bogus unmap come from unprivileged tenant code rather than from the operator. NVD rates it local availability impact only; nothing in the record indicates memory disclosure across tenants.

Who can reach it

Local user with access to /dev/infiniband/uverbs* - in practice any tenant container given RDMA device access. No special privilege beyond that device handle; not reachable from the network or from a node without verbs exposure.

What to do

Pick up the fix in your distribution kernel (upstream commits linked in the record) and reboot the node; mlx5_ib cannot be reloaded under live RDMA workloads, so this lands in a normal drain-and-reboot cycle. If you do not expose verbs devices into tenant containers there is no local trigger and the fix can wait for the next scheduled kernel roll.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-21888 https://git.kernel.org/stable/c/f1298cad47ae29828c5c5be77e733ccfcaef6a7f https://git.kernel.org/stable/c/8fe3c674ef289cdc0760fe787e7584d805ab9301

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.