CVE-2026-46178

What it actually does

This is a local Linux kernel vulnerability in the RDMA mlx4 driver error-handling path. When mlx4_ib_create_srq() fails after mlx4_srq_alloc() has succeeded, the allocated shared receive queue resource is not released because the error unwind path omits mlx4_srq_free(). A local user able to reach the mlx4 RDMA verbs interface can repeatedly trigger this failure path, causing kernel or adapter resource leakage. Depending on kernel build, device availability, and surrounding memory/resource pressure, the impact can include denial of service, kernel instability, and potentially broader compromise consistent with the assigned high confidentiality, integrity, and availability impact. The issue is local-only, requires low privileges, and does not require user interaction.

Why it matters to the business

Systems using Linux kernels with Mellanox/ConnectX mlx4 RDMA support may be exposed to local abuse that can degrade or crash workloads that depend on RDMA, high-performance networking, storage fabrics, or clustered compute. Because exploitation requires local access and there is no known public exploit or CISA KEV listing, this is not currently an internet-scale emergency, but it should be prioritized on multi-user Linux systems, HPC environments, virtualization hosts, container hosts with RDMA device access, and production systems where RDMA outages would disrupt critical services.

How an attack unfolds

An attacker first obtains local access to a vulnerable Linux system with the affected mlx4 RDMA driver loaded and accessible RDMA hardware or device interfaces. The attacker then uses RDMA verbs or a crafted local program to request creation of shared receive queues in a way that causes mlx4_srq_alloc() to succeed but a later operation in mlx4_ib_create_srq() to fail. Because the error path does not free the allocated mlx4 SRQ resource, each failed request leaves resources behind. By repeating the sequence, the attacker can consume kernel, driver, or adapter resources until legitimate RDMA operations fail, the driver becomes unstable, or the host requires intervention. There are no named threat actors, ransomware campaigns, or public exploit maturity reported for this issue at this time.

How to fix it

Apply the Linux kernel update from the operating system or kernel vendor that includes the RDMA/mlx4 fix adding the missing mlx4_srq_free() call in the mlx4_ib_create_srq() error path. No universal upstream fixed version was provided in the input, so remediation should be tracked through the relevant distribution advisory, vendor kernel package, or stable kernel branch. After updating, reboot into the patched kernel or otherwise ensure the patched mlx4_ib module is loaded. If immediate patching is not possible, reduce exposure by unloading or blacklisting mlx4_ib where RDMA is not required, restricting access to RDMA device nodes and verbs interfaces, limiting local shell/container access on affected hosts, and applying resource controls to untrusted workloads. Systems without mlx4 RDMA hardware or without the mlx4_ib driver loaded are materially less exposed to practical exploitation.

How to confirm the fix worked

Confirm the system is running a vendor kernel build that contains the RDMA/mlx4 fix for the missing mlx4_srq_free() unwind path. Validate the active kernel with uname -r and package-manager metadata, not only installed-but-inactive packages. Check whether the mlx4_ib module is loaded using lsmod or /sys/module/mlx4_ib, and confirm whether mlx4 RDMA devices are present with rdma link, ibv_devinfo, or lspci. If the module is not needed, verify it remains unloaded after reboot and is blocked by modprobe configuration. For patched systems that still use RDMA, run vendor-appropriate RDMA smoke tests and monitor dmesg/journalctl for mlx4, SRQ, or RDMA allocation errors under normal load. Exposure is considered reduced when the active kernel contains the fix, untrusted users cannot access RDMA interfaces, or mlx4_ib is absent/unloaded on systems that do not require it.

Typical attack path

1. Gain local low-privileged access to a Linux system running an affected kernel with mlx4 RDMA support present.
2. Confirm that mlx4-related RDMA devices or userspace verbs interfaces are available to the account or workload context.
3. Run a program that repeatedly invokes SRQ creation through the RDMA verbs interface while forcing a later failure in mlx4_ib_create_srq().
4. Trigger the vulnerable error unwind path where mlx4_srq_alloc() succeeds but mlx4_srq_free() is not called.
5. Accumulate leaked SRQ, kernel, or adapter resources over repeated attempts.
6. Cause RDMA service degradation, application failures, kernel instability, or denial of service; in worst-case conditions, attempt to leverage instability for broader local compromise.

How to detect it

There is no reliable single log entry that proves exploitation, and no public exploit-specific indicators are known. Detection should focus on suspicious local activity combined with affected-driver telemetry. Review kernel logs from journald, dmesg, /var/log/kern.log, /var/log/messages, and crash dumps for repeated mlx4, mlx4_ib, RDMA, verbs, or SRQ allocation/create failures. Correlate those events with auditd, process accounting, EDR, shell history, container runtime logs, HPC/job scheduler logs, and sudo/session logs to identify users or workloads repeatedly interacting with RDMA devices. Look for abnormal growth in RDMA resource usage, failures from legitimate RDMA applications, unexpected processes opening /dev/infiniband/*, or repeated short-lived test binaries invoking libibverbs. On systems that crashed or hung, preserve vmcore, pstore, kdump, and journal logs before reboot cleanup. Absence of these artifacts does not rule out exploitation because this is a local kernel-driver bug and failed resource cleanup may leave limited forensic evidence.

• mlx4_ib
• mlx4_core
• mlx4_ib_create_srq
• mlx4_srq_alloc
• mlx4_srq_free
• create_srq
• SRQ
• shared receive queue
• /sys/module/mlx4_ib
• /dev/infiniband/
• libibverbs
• ibv_create_srq
• rdma_create_id

What your security team should do

• Prioritize patching Linux hosts that have Mellanox/ConnectX mlx4 RDMA hardware, the mlx4_ib module loaded, or RDMA device access exposed to users, containers, or batch jobs.
• Inventory systems for mlx4_ib usage using kernel module telemetry, package inventory, lspci, rdma tooling, and configuration management data.
• On multi-user, HPC, virtualization, and container platforms, restrict access to RDMA devices and userspace verbs interfaces until patched.
• If RDMA is not required, unload and blacklist mlx4_ib and confirm the change persists across reboot.
• Monitor kernel logs for repeated mlx4, RDMA, and SRQ allocation failures, especially from the same user, process, container, or job context.
• Treat suspicious repeated RDMA allocation failures as potential local abuse and investigate correlated process execution, user sessions, container launches, and job scheduler activity.
• Because EPSS is currently very low and no KEV or public exploit maturity is reported, prioritize based on local exposure and operational criticality rather than broad emergency response.