CVE-2026-46176: Linux Kernel Use-After-Free Vulnerability

CVE-2026-46176 Overview

CVE-2026-46176 is a Linux kernel vulnerability in the Mellanox mlx5 InfiniBand (IB) RDMA driver. The defect lives in mlx5_ib_dev_res_srq_init(), which allocates two Shared Receive Queues (SRQs), s0 and s1. When ib_create_srq() fails for s1, the error branch destroys s0 but falls through and unconditionally assigns the freed s0 and the ERR_PTRs1 to devr->s0 and devr->s1. Subsequent code paths treat these values as valid initialized objects, leading to use-after-free, ERR_PTR dereference, and double-free conditions during teardown.

Critical Impact

Failed SRQ initialization leaves freed and ERR_PTR values stored as live driver resources, enabling kernel memory corruption through use-after-free, double-free, and invalid pointer dereferences in the RDMA fast path.

Affected Products

• Linux kernel (RDMA mlx5 driver) — specific affected versions are not enumerated in the NVD record
• Mellanox ConnectX-family adapters using the mlx5_ib driver stack
• Distributions shipping kernels prior to the fix commits referenced in the kernel.org stable tree

Discovery Timeline

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

Technical Details for CVE-2026-46176

Vulnerability Analysis

The mlx5_ib_dev_res_srq_init() function initializes two SRQs used by the RDMA mlx5 device resources structure (devr). The intended pattern allocates s0 first, then s1, with both committed to devr only when both succeed. The bug is a missing goto unlock in the s1 failure branch. After ib_create_srq() returns an error for s1, the code destroys s0 but does not jump out of the function. Execution falls through to the assignment block, where the now-freed s0 pointer and the ERR_PTR-encoded s1 are stored into devr->s0 and devr->s1.

Root Cause

The root cause is improper error-path control flow [CWE-755]. The fast-path check if (devr->s1) return 0; interprets any non-NULL value, including an ERR_PTR, as a fully initialized SRQ. Callers in mlx5_ib_create_qp() then dereference the freed object via to_msrq(devr->s0)->msrq.srqn, producing a use-after-free read. On driver teardown, mlx5_ib_dev_res_cleanup() dereferences the ERR_PTR for s1 and double-frees the already-released s0. The defect class is a combined Use-After-Free, Double Free, and invalid pointer dereference triggered by an unhandled allocation failure.

Attack Vector

Triggering the bug requires the s1 SRQ allocation to fail while s0 succeeds. This is reachable when the kernel encounters memory pressure or mlx5 firmware/resource constraints during device bring-up. Any local workload that drives the RDMA subsystem under those conditions can reach the corrupted state. Subsequent QP creation or device cleanup then dereferences the poisoned pointers, producing kernel oops, potential memory corruption, or — depending on heap layout — exploitable conditions for local privilege escalation. The fix adds the missing goto unlock so the failure path leaves devr->s0 and devr->s1 uninitialized and the function returns the original error.

No verified public exploit code is available. See the kernel commit references for the patch diffs.

Detection Methods for CVE-2026-46176

Indicators of Compromise

• Kernel oops, BUG, or KASAN reports referencing mlx5_ib_dev_res_srq_init, mlx5_ib_create_qp, or mlx5_ib_dev_res_cleanup
• use-after-free or double-free splats in dmesg involving to_msrq or msrq.srqn
• ib_create_srq failure messages from the mlx5_ib driver immediately followed by QP creation errors
• Unexpected crashes during RDMA-enabled workload startup or mlx5 driver unload

Detection Strategies

• Enable KASAN on test kernels to surface the use-after-free read in to_msrq(devr->s0)->msrq.srqn
• Audit running kernels with uname -r against the fix commits 6fd93142dd1d, a13c2ac4d480, b087913ae882, bc2cf5935b46, and c488df06bd55
• Correlate mlx5_ib error messages with subsequent QP or SRQ failures in centralized log pipelines

Monitoring Recommendations

• Forward journald and dmesg from RDMA hosts to a central log store and alert on mlx5_ib plus BUG, oops, or KASAN keywords
• Track kernel package versions across the fleet and flag hosts running pre-patch builds of the mlx5_ib driver
• Monitor RDMA-dependent services (NVMe-oF, GPUDirect, Lustre, Ceph) for restart loops that may indicate triggered SRQ init failures

How to Mitigate CVE-2026-46176

Immediate Actions Required

• Update affected hosts to a Linux kernel build that includes the fix commits listed in the kernel.org stable references
• Inventory all systems with Mellanox ConnectX hardware loading the mlx5_ib module and prioritize them for patching
• Restrict local access on RDMA-enabled hosts until patched kernels are deployed

Patch Information

The fix adds the missing goto unlock in the s1 failure path so that the function returns the propagated error without storing freed or ERR_PTR values into devr->s0 and devr->s1. The change is available across multiple stable branches via the following commits: 6fd93142dd1d, a13c2ac4d480, b087913ae882, bc2cf5935b46, and c488df06bd55. Apply the distribution kernel update that incorporates these commits and reboot affected hosts.

Workarounds

• Unload the mlx5_ib module on hosts that do not require RDMA functionality using modprobe -r mlx5_ib
• Blacklist mlx5_ib in /etc/modprobe.d/ where RDMA is not in production use
• Reduce conditions that cause SRQ allocation failures by avoiding memory-pressure scenarios during RDMA device bring-up until patched kernels are deployed

# Configuration example
# Verify whether the running kernel still loads the vulnerable driver
lsmod | grep mlx5_ib

# Temporarily unload the driver on non-RDMA hosts
sudo modprobe -r mlx5_ib

# Persistently blacklist mlx5_ib where RDMA is not required
echo 'blacklist mlx5_ib' | sudo tee /etc/modprobe.d/blacklist-mlx5_ib.conf
sudo update-initramfs -u