CVE-2026-46178: Linux Kernel Resource Leak Vulnerability

CVE-2026-46178 Overview

CVE-2026-46178 is a resource leak vulnerability in the Linux kernel's RDMA/mlx4 InfiniBand driver. The flaw resides in the mlx4_ib_create_srq() function, which handles the creation of Shared Receive Queues (SRQ) for Mellanox ConnectX-3 adapters. When an error occurs after mlx4_srq_alloc() succeeds, the error unwind path fails to call mlx4_srq_free(), leaving allocated SRQ resources orphaned in the device. Repeated failures can exhaust kernel and device resources, leading to degraded system stability on hosts using mlx4-based RDMA hardware.

Critical Impact
Repeated invocations of the affected code path on error conditions can exhaust SRQ resources within the mlx4 driver, contributing to denial-of-service conditions on RDMA-enabled Linux systems.

Affected Products

Linux kernel versions containing the RDMA/mlx4 driver prior to the patched commits
Systems using Mellanox ConnectX-3 (mlx4) InfiniBand or RoCE adapters
Distributions shipping unpatched stable kernel branches referenced in the upstream fixes

Discovery Timeline

2026-05-28 - CVE-2026-46178 published to NVD
2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-46178

Vulnerability Analysis

The vulnerability is a memory and resource leak in the mlx4_ib_create_srq() function within the Linux kernel's RDMA subsystem driver for Mellanox ConnectX-3 hardware. The function is responsible for allocating an SRQ object that user-space RDMA consumers request through the ibv_create_srq() verb. During the allocation sequence, mlx4_srq_alloc() reserves hardware and software state for the queue. If a subsequent step in mlx4_ib_create_srq() fails, the function falls through to its cleanup path. That cleanup path omits the corresponding mlx4_srq_free() call, so the previously allocated SRQ state is never released.

Each failed creation attempt therefore leaks an SRQ index, associated firmware context, and kernel bookkeeping structures. Over time, this can starve the device of available SRQ slots and the kernel of memory.

Root Cause

The root cause is an incomplete error-unwind path inside mlx4_ib_create_srq(). The function pairs allocation and free routines symmetrically for most resources, but the call to mlx4_srq_alloc() lacks its symmetric mlx4_srq_free() on the failure goto target. The upstream fix, identified by Sashiko, adds the missing mlx4_srq_free() invocation so all allocated state is released on error.

Attack Vector

Exploitation requires the ability to invoke the RDMA verbs interface and force an error after mlx4_srq_alloc() succeeds. A local user with permission to open /dev/infiniband/uverbsN devices can repeatedly trigger SRQ creation with parameters that fail later in the allocation sequence. Each failure leaks resources. The attack vector is local and constrained to systems with mlx4 hardware exposing RDMA verbs to unprivileged or container workloads.

The vulnerability is a resource leak rather than a memory corruption issue. No code execution primitive is associated with the flaw. Technical details for each backport are available in the upstream commits: Kernel Patch 0dbd619716, Kernel Patch 388617f44d, Kernel Patch c54c7e4cb6, Kernel Patch c5dc30da99, and Kernel Patch e01b8c9286.

Detection Methods for CVE-2026-46178

Indicators of Compromise

Growing kernel slab consumption attributed to mlx4_ib or RDMA allocations without corresponding releases over time.
Repeated failed IB_USER_VERBS_CMD_CREATE_SRQ calls visible in audit logs or strace of RDMA-using workloads.
dmesg warnings from the mlx4 driver about SRQ index exhaustion or allocation failures after extended uptime.

Detection Strategies

Track the kernel version against the patched commits and flag hosts running unpatched mlx4-enabled kernels.
Monitor RDMA verb syscall return codes for clusters of failed create_srq operations originating from the same UID or container.
Compare baseline versus current SRQ counts via /sys/class/infiniband/ device statistics on long-running RDMA hosts.

Monitoring Recommendations

Alert on sustained increases in mlx4 driver slab caches and on InfiniBand device resource counters reported by rdma resource show.
Audit which workloads hold capability CAP_NET_RAW or have access to /dev/infiniband/* and constrain them where unnecessary.
Capture kernel ring buffer messages with telemetry pipelines to retain mlx4 warnings for post-incident review.

How to Mitigate CVE-2026-46178

Immediate Actions Required

Apply the upstream stable kernel updates that include the mlx4_srq_free() cleanup fix and reboot affected hosts.
Inventory all systems with Mellanox ConnectX-3 adapters and prioritize patching where RDMA is exposed to multi-tenant or container workloads.
Restrict access to /dev/infiniband/uverbs* devices to trusted users and service accounts only.

Patch Information

The fix adds the missing call to mlx4_srq_free() on the error path of mlx4_ib_create_srq(). Backports are available across multiple stable kernel branches. Reference the following commits to confirm patch presence in your kernel source: Kernel Patch 0dbd619716, Kernel Patch 388617f44d, Kernel Patch c54c7e4cb6, Kernel Patch c5dc30da99, and Kernel Patch e01b8c9286.

Workarounds

Unload the mlx4_ib module on hosts that do not require RDMA functionality until a patched kernel is deployed.
Restrict the InfiniBand uverbs interface from untrusted container workloads using device cgroup controls or seccomp.
Schedule periodic reboots of long-running RDMA hosts to reclaim leaked SRQ state where patching is delayed.

bash

# Restrict mlx4 RDMA verbs access to trusted group only
sudo groupadd rdma-trusted
sudo chgrp rdma-trusted /dev/infiniband/uverbs*
sudo chmod 660 /dev/infiniband/uverbs*

# Optional: disable mlx4_ib where RDMA is not required
sudo modprobe -r mlx4_ib
echo "blacklist mlx4_ib" | sudo tee /etc/modprobe.d/disable-mlx4_ib.conf