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

CVSS 7.8CVE-2026-53133Firmware, BMC & network fabriccurated

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

https://git.kernel.org/stable/c/2ff4b7817e5b78070c30f5fb5e678e452a2628b3 https://git.kernel.org/stable/c/dee2a49adeeb2a5e16a3fc858fa21b841c519802 https://nvd.nist.gov/vuln/detail/CVE-2026-53133

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.