Linux mlx5_ib: transport domain leaked when loopback enable fails during RDMA device setup

Impact

On ConnectX adapters, mlx5_ib_alloc_transport_domain() allocates a transport domain and then can fail in mlx5_ib_enable_lb(); on that error path the transport domain is never deallocated. Each failed allocation burns a firmware transport-domain resource, so repeated failures can exhaust them and stop further RDMA protection-domain or QP setup on that adapter - a GPU node whose RDMA stack will not initialise is effectively out of the training job. The lb mutex was also initialised too late, which the same fix moves into stage init. This is a resource-management bug on an error path, not a memory-corruption primitive; the 7.8 CVSS score from the kernel CNA is the generic rating applied to the batch, not a demonstrated local privilege escalation.

Who can reach it

Local user or container that can open an InfiniBand/RoCE verbs device (/dev/infiniband/*) and drive transport-domain allocation - on a GPU cluster, any tenant pod given RDMA device access. No remote or unauthenticated path is described.

What to do

Pick up the fixed stable kernel for your series (five stable commits listed in the record) and reboot each affected node; there is no documented runtime mitigation other than keeping RDMA device access off untrusted tenants. Reloading mlx5_ib alone is not a supported substitute on a node running RDMA jobs, so plan this with the normal drain-and-reboot cycle.

References

Related entries

• Dell OMSA: local heap overflow lets a low-privileged user escalate on the GPU hostCVE-2026-81474 · Dell OpenManage Server Administrator (managed node, heap-based buffer overflow)High
• Linux RDMA bnxt_re: destroy callbacks re-run against freed resources after a udata failureCVE-2026-93277 · Linux kernel RDMA/bnxt_re (udata validation in destroy/create paths)High
• Linux RDMA core: integer truncation and overflow when picking a memory-region page sizeCVE-2026-97421 · Linux kernel RDMA/umem (ib_umem_find_best_pgsz boundary handling)High
• AMD erratum #1718: INVLPGB/TLBSYNC may fail to invalidate a TLB entryCVE-2026-99099 · AMD x86 processors (INVLPGB/TLBSYNC broadcast TLB invalidation, erratum #1718)High
• AMI MegaRAC SPx 13 (IPMI handler / host SPI flash path): The multi-tenant bare-metal nightmareCVE-2023-34335 · AMI MegaRAC SPx 13 (IPMI handler / host SPI flash path)High
• Linux kernel occ hwmon: truncated OCC poll response is parsed past the valid dataCVE-2026-68340 · Linux kernel occ hwmon driver (IBM POWER OCC poll response parser)High