CVE-2026-46176

What it actually does

This is a Linux kernel memory-safety flaw in the Mellanox/NVIDIA mlx5 RDMA driver error-handling path. During mlx5_ib_dev_res_srq_init(), if creation of the second shared receive queue fails, the driver destroys the first queue but then incorrectly stores stale and error-pointer values as initialized device resources. Later code may treat those invalid pointers as valid, causing use-after-free, invalid pointer dereference, double-free during cleanup, kernel crash, and potentially local privilege escalation or arbitrary kernel memory corruption in configurations where the mlx5 RDMA driver is present and reachable by a local user.

Why it matters to the business

Organizations running Linux systems with mlx5 RDMA-capable networking hardware or the mlx5 RDMA driver enabled could face local denial of service or, in a worst case, privilege escalation from a low-privileged local account to kernel-level control. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score, so broad internet-scale exploitation is unlikely; however, the high CVSS impact means exposed multi-user compute, HPC, AI/ML, virtualization, storage, and low-latency networking hosts should still be prioritized for kernel updates.

How an attack unfolds

An attacker first needs local access to a Linux host where the mlx5 RDMA stack is loaded and usable. They then attempt to trigger the mlx5_ib_dev_res_srq_init() error path by causing creation of the second SRQ to fail while the first SRQ has already been allocated. Because the failed path leaves devr->s0 and devr->s1 pointing to freed or invalid objects, subsequent RDMA queue-pair creation or cleanup paths may dereference those invalid pointers. Depending on allocator state, kernel configuration, and timing, the result may be an immediate kernel oops/panic, a double-free, or exploitable use-after-free memory corruption that could allow privilege escalation. There is no indication from the provided intelligence that public weaponized exploitation exists, and exploitation is constrained to local access plus affected RDMA/mlx5 configurations.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the upstream fix for RDMA/mlx5: adding the missing goto unlock in the s1 failure path of mlx5_ib_dev_res_srq_init(). Because no exact fixed versions were provided, use the latest security-supported kernel from the operating system or appliance vendor and confirm the vendor advisory explicitly includes the fix for this CVE or the referenced RDMA/mlx5 patch. Reboot into the updated kernel after patching. Where immediate patching is not possible, reduce exposure by unloading or disabling the mlx5_ib RDMA driver if RDMA is not required, restricting local shell access, limiting RDMA device access to trusted users only, and disabling unneeded InfiniBand/RDMA services and device nodes. These mitigations reduce exploitability but do not replace applying the kernel fix.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking uname -r after reboot and comparing it to the vendor-fixed kernel release. Verify the fix is present by reviewing the vendor changelog or source package for the RDMA/mlx5 change in mlx5_ib_dev_res_srq_init() that routes the s1 failure path to unlock without storing freed or ERR_PTR resources. Check whether affected functionality is present by looking for loaded modules such as mlx5_ib, mlx5_core, ib_core, and rdma_cm with lsmod, and by enumerating RDMA devices with rdma link or ibv_devinfo. If RDMA is not required, validate that mlx5_ib is not loaded after reboot and is blocked from autoloading. In staging environments with mlx5 RDMA hardware, run RDMA application smoke tests after patching to ensure normal queue-pair creation and cleanup still function without kernel warnings.

Typical attack path

1. Obtain low-privileged local access to a Linux system with mlx5 RDMA functionality available.
2. Confirm the mlx5_ib driver and RDMA device resources are present or loadable.
3. Exercise RDMA verbs or queue-pair creation paths that invoke mlx5_ib_dev_res_srq_init().
4. Force or induce failure while creating the second shared receive queue so the vulnerable error branch executes.
5. Trigger later code paths that dereference devr->s0 or devr->s1, such as queue-pair creation or device-resource cleanup.
6. Cause a kernel crash for denial of service or attempt to shape heap state for privilege escalation through use-after-free memory corruption.

How to detect it

Look for evidence of attempted or successful exploitation in kernel, audit, and system availability logs on hosts with mlx5 RDMA drivers loaded. Relevant log sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, oops reports, and EDR telemetry for local processes interacting with RDMA devices. Hunt for kernel oops or panic messages mentioning mlx5_ib_dev_res_srq_init, mlx5_ib_create_qp, mlx5_ib_dev_res_cleanup, to_msrq, ib_create_srq, use-after-free, double free, general protection fault, BUG, WARNING, KASAN, KFENCE, or invalid pointer dereference. Correlate crashes with local user sessions, container workloads, RDMA benchmarking tools, or applications opening /dev/infiniband devices shortly before the event. Because exploitation may only produce a crash and no stable user-space artifact, absence of IOCs does not prove absence of exploitation. There are no known threat actors, ransomware campaigns, or public exploit signatures in the supplied intelligence.

• mlx5_ib_dev_res_srq_init
• mlx5_ib_create_qp
• mlx5_ib_dev_res_cleanup
• to_msrq
• ib_create_srq
• mlx5_ib
• mlx5_core
• /dev/infiniband/uverbs
• /dev/infiniband/rdma_cm
• use-after-free
• double free
• general protection fault
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• KASAN: use-after-free
• KFENCE: use-after-free
• kernel panic
• Oops:
• RIP: mlx5_ib_create_qp
• RIP: mlx5_ib_dev_res_cleanup
• RIP: mlx5_ib_dev_res_srq_init

What your security team should do

• Prioritize patching Linux hosts that combine local multi-user access with mlx5 RDMA-capable NICs, InfiniBand, RoCE, HPC, AI/ML, storage, or low-latency networking workloads.
• Inventory systems with mlx5_ib or related RDMA modules loaded and separate them from Linux hosts that are not exposed to this driver path.
• Apply the latest vendor-supported kernel containing the RDMA/mlx5 fix and reboot systems to activate it.
• If patching is delayed, disable or unload mlx5_ib where RDMA is not business-critical and restrict access to RDMA device nodes and RDMA-enabled workloads.
• Monitor kernel logs for mlx5_ib crashes, use-after-free reports, general protection faults, KASAN reports, and unexpected reboots on systems with mlx5 hardware.
• Treat suspicious local activity around RDMA device access on shared compute systems as higher priority, even though current exploitation likelihood is low.
• Track vendor advisories because fixed package names and versions vary across distributions and may be delivered as backported kernel updates rather than a visibly newer upstream kernel version.