Linux kernel mlx5_ib: implicit ODP parent mkey re-registered in place, racing its child mkeys and mr->pd

UnscoredCVE-2026-80880Firmware, BMC & network fabriccurated

Impact

With implicit on-demand paging the parent mkey owns a tree of child mkeys, so nothing about it can be changed in place; the driver nonetheless allowed rereg_mr to mutate it, and implicit children were also touching mr->pd, which the commit message calls out as a further racy access. The fix forces implicit values when the user supplies no translation, so the request falls through to mlx5_ib_reg_user_mr() and a wholly new MR is allocated instead. This is the ConnectX RDMA path that GPUDirect and multi-node training traffic ride on, so the blast radius is a fabric-facing driver on every node in a training job. The record does not state an exploitability outcome or a score, and there is no CVSS in it - treat it as a memory-region lifetime bug reachable from local RDMA users, not as a demonstrated remote compromise.

Who can reach it

Local user with access to the uverbs device on an mlx5 host who can register an implicit ODP memory region and then call rereg_mr on it. No authentication beyond access to the RDMA device, which tenants get whenever RDMA is exposed into their pods.

What to do

Take the stable commits in the record; the record gives no fixed version string. Rolling it out is a kernel update and a node reboot, which for RDMA nodes usually means draining a whole training job rather than one pod. There is no mitigation short of not exposing ODP-capable RDMA registration to untrusted tenants.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-80880 https://git.kernel.org/stable/c/5d02b9a2efd11d28d2a8feac7769686b1b871d9c https://git.kernel.org/stable/c/eb7cb798e563b3f3b3baeb9cc6f7455764267e50

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.