GPU VulnDB

Database/Firmware, BMC & network fabric

Linux kernel mlx4 InfiniBand driver: SRQ leaked on create failure, exhausting fabric resources

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

Impact

mlx4_ib_create_srq() allocated a shared receive queue through mlx4_srq_alloc() and, on a later error, returned without calling mlx4_srq_free(). Every failed SRQ creation permanently burns a hardware SRQ slot on the ConnectX-3 adapter. A local user holding an RDMA device - which on a GPU cluster means any tenant whose pod gets the verbs device for NCCL or MPI - can repeat the failing call to drain the adapter's SRQ table, after which RDMA queue-pair setup fails for everyone on that host. That turns a leak into a fabric-level denial of service on a shared node: collectives stop forming and the node has to be rebooted to recover the adapter state. NVD rates it 7.8 local; the leak itself is the established effect, nothing in the record points to memory disclosure or code execution.

Who can reach it

Local, authenticated. A user or container with access to an mlx4 RDMA device node (/dev/infiniband/uverbsN) who can make SRQ creation fail repeatedly. Not reachable from the network, and not reachable at all on hosts with no ConnectX-3 class adapter.

What to do

Update to a fixed stable kernel and reboot the affected hosts. mlx4 covers ConnectX-3 and ConnectX-3 Pro only, so inventory first - modern ConnectX-5/6/7 fleets run mlx5 and are not affected. For nodes that are affected, the practical interim control is to stop handing raw verbs devices to untrusted tenants.

References

Related entries

All Firmware, BMC & network fabric entries

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.