Linux kernel (drivers/infiniband/core): When the IOMMU coalesces a large memory registration into one block spanning

Impact

When the IOMMU coalesces a large memory registration into one block spanning several scatter entries, the umem block iterator reassembles it with 32-bit arithmetic and computes wrong DMA addresses for everything past the 4GB boundary. The HCA is then programmed to DMA into physical memory the tenant never registered, so a remote peer's RDMA writes against a legitimate rkey land in someone else's pages.

Who can reach it

Reachable by any tenant container holding /dev/infiniband/uverbs* that registers a memory region larger than 4GB (ibv_reg_mr) on a node where the IOMMU linearises the mapping - which is ordinary behaviour for GPU training jobs with large pinned buffers. No fabric peer is needed to create the bad mapping; once it exists, any RDMA peer writing to that rkey writes to the wrong physical memory.

What to do

No fixed version is listed in the record - take the stable kernel carrying commit 2ff4b7817e5b (or the backports dee2a49adeeb / cc644d5608e3) and reboot the node. There is no realistic interim control: capping registrations below 4GB is not workable for GPU workloads, so patch rather than mitigate.

References