librdmacm 1.0.16 (userspace RDMA connection-manager library) - default fallback to ibacm port 6125: RDMA

Impact

RDMA address-resolution poisoning, in the library every verbs application links against. When ibacm.port is unset, librdmacm silently falls back to connecting to port 6125 and trusts whatever ib_acm service answers there for its path records - GID, LID and path attributes. Whoever answers therefore decides where a victim application's queue pairs actually get established. This is the RDMA-layer equivalent of DNS or ARP poisoning, and it is worse than either because RDMA has no transport authentication to catch the redirect afterwards: the QP comes up, the RDMA operations succeed, and the tenant's gradients or checkpoints land at an endpoint of the attacker's choosing. It is also the one item in this collection that lives entirely in userspace, so no kernel patching regime catches it.

Who can reach it

Whoever can bind or answer on the ibacm port that the victim's librdmacm falls back to - a co-located process on the same node, or a rogue ib_acm reachable across the fabric. Chains directly from CVE-2012-4518, which lets any local user rewrite the ibacm.port file that decides where librdmacm looks.

What to do

Update librdmacm past 1.0.16 (upstream commit 4b5c1aa734e0e734fc2ba3cd41d0ddf02170af6d) and explicitly pin ibacm.port rather than relying on the default. This is a userspace library, so the fix lands with a package update and a restart of the RDMA-using applications - no kernel reboot - but that is also the trap: it will not appear in any kernel CVE scan, and containerised AI workloads frequently ship their own vendored copy of the RDMA userspace stack inside the image, which means patching the host does nothing. Audit the librdmacm version inside your tenant base images, not just on the host.

References