Linux kernel mlx5_ib: kernel memory leak on the RDMA data-direct sysfs path query

CVSS 5.5CVE-2026-45922Firmware, BMC & network fabriccurated

Impact

A local user holding an RDMA device file can repeatedly call the mlx5 GET_DATA_DIRECT_SYSFS_PATH uverbs method with an undersized output buffer. Each failing call allocates the device path via kobject_get_path() and returns -ENOSPC without freeing it, so unprivileged-but-RDMA-capable code can leak unreclaimable kernel memory in a loop. On a GPU node where tenants get direct access to the ConnectX verbs interface for NCCL or RDMA storage, that is an availability problem on a host that is expensive to drain. No information disclosure or privilege escalation is described in the record.

Who can reach it

Local user with access to an InfiniBand/RoCE uverbs device node (/dev/infiniband/uverbs*) on a host with a mlx5 data-direct device; no elevated privileges beyond that device access are described. Not reachable from the network.

What to do

Pick up the fixed stable kernel (four stable commits are linked) and reboot each affected node; there is no runtime mitigation short of denying tenants uverbs access. Treat it as a rolling node-drain-and-reboot item folded into the next kernel maintenance window rather than an emergency.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-45922 https://git.kernel.org/stable/c/9b9d253908478f504297ac283c514e5953ddafa6 https://git.kernel.org/stable/c/b3a10eca24fcfe913c0875e620f19596001bd6dc https://git.kernel.org/stable/c/ee998cdbff6680891b0efd9d6ce53a388e5342c3

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.